Wireless patient communicator employing security information management

ABSTRACT

A patient communicator for communicating with a patient implantable medical device (PIMD) and facilitating communications with a remote server via a wireless network. The communicator has a housing configured for portability, and an identity module to store subscriber identification data. A processor is coupled to the identity module and is configured to prevent data exchange with the PIMD unless the identity module is authorized for use. Memory coupled to the processor stores wireless radio firmware and medical firmware. A first radio is configured to effect communications with the PIMD in accordance with execution of the medical firmware by the processor. A second radio is configured to effect communications via a channel of the wireless network with a remote server in accordance with execution of the wireless radio firmware by the processor. The processor is generally configured to use subscriber identification data to facilitate authentication by and of the remote server.

RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.12/151,910, filed on May 9, 2008, which claims the benefit ofProvisional Patent Application Ser. Nos. 60/967,060, 60/967,061,60/967,062, and 60/967,063 each filed on Aug. 31, 2007, to whichpriority is claimed pursuant to 35 U.S.C. §119(e) and which are herebyincorporated herein by reference in their entireties.

FIELD OF THE INVENTION

The present invention relates generally to systems, devices, and methodsfor securely transporting medical information over a wireless network.

BACKGROUND

Implantable pulse generators (IPGs) are medical devices commonly used totreat irregular heartbeats, known as arrhythmias. Cardiac pacemakers,for example, are designed to manage bradycardia, an abnormally slow orirregular heartbeat. Left untreated, bradycardia can cause symptoms suchas fatigue, dizziness, and fainting. Cardiac resynchronizers are aparticular class of pacemaker that provide cardiac resynchronizationtherapy, such a bi-ventricular pacing, for patients suffering from heartfailure. Implantable cardioverter defibrillators (ICDs), by way offurther example, are designed to treat tachycardia, heart rhythms thatare abnormally fast and life threatening. Some forms of tachycardia canresult in sudden cardiac death, if left untreated.

Pacemakers and ICDs are increasingly being equipped with an on-board,volatile memory in which telemetered signals can be stored for laterretrieval and analysis. The telemetered signals provide various types ofpatient device information, such as atrial electrical activity,ventricular electrical activity, time of day, activity level, cardiacoutput, oxygen level, cardiovascular pressure measures, pulmonarymeasures, and any interventions made on a per heartbeat or binnedaverage basis. In addition, a growing class of cardiac medical devices,including implantable heart failure monitors, implantable eventmonitors, cardiovascular monitors, and therapy devices, are being usedto provide similar stored device information. These devices aretypically designed to store approximately thirty minutes of heartbeatdata. Telemetered signals are also stored in a broader class of monitorsand therapeutic devices for other areas of medicine, includingmetabolism, endocrinology, hematology, neurology, muscular,gastrointestinal, genital-urology, ocular, auditory, and the like.

Information stored in an implantable medical device is typicallyretrieved using a proprietary interrogator or programmer, often during aclinic visit or following a device event. The volume of data retrievedfrom a single device interrogation procedure can be large and properinterpretation and analysis can require significant physician time anddetailed subspecialty knowledge, particularly by cardiologists andcardiac electrophysiologists. Present approaches to data interpretationand understanding, and practical limitations on time and physicianavailability, make such analyses impracticable.

Conventional systems for collecting and analyzing pacemaker and ICDtelemetered signals in a clinical or office setting can be used toretrieve data, such as patient electrocardiogram and any measuredphysiological conditions, collected by the IPG for recordation, displayand printing. The retrieved data may displayed in chronological orderand analyzed by a physician. Conventional systems often lack remotecommunications facilities and must be operated with the patient present.These systems present a limited analysis of the collected data based ona single device interrogation and lack the capability to recognizetrends in the data spanning multiple episodes over time or relative to adisease specific peer group.

SUMMARY OF THE INVENTION

The present invention is directed to systems, devices, and methods forsecurely transporting medical information over a wireless network. Inone embodiment, a patient communicator is described for communicatingwith a patient implantable medical device (PIMD) and facilitatingcommunications with a remote server via a wireless network. The patientcommunicator has a housing configured for portability by an ambulatorypatient and an identity module disposed in the housing that isconfigured to store subscriber identification data. A processor iscoupled to the identity module in the housing and is configured toprevent data exchange with the PIMD unless the identity module isauthorized for use. Memory disposed in the housing and coupled to theprocessor comprises wireless radio firmware and medical firmware, wherethe medical firmware is generally executable by the processor tofacilitate communication with the PIMD. A first radio is disposed in thehousing and is configured to effect communications with the PIMD inaccordance with execution of the medical firmware by the processor. Asecond radio is disposed in the housing and is configured to effectcommunications via a channel of the wireless network with a remoteserver in accordance with execution of the wireless radio firmware bythe processor. The processor is generally configured to use at least thesubscriber identification data to facilitate authentication by theremote server and facilitate authentication of the remote server.

In another embodiment a patient communicator is described forcommunicating with a PIMD and for facilitating communications with aremote server via a wireless network. A housing of the communicator isgenerally configured for portability by an ambulatory patient. Anidentity module is detachably disposed in the housing and configured tostore at least identity data that uniquely identifies the patientcommunicator as being associated with the patient. The identity data canhave physiologic data obtained from the patient. A processor is coupledto the identity module, and is configured to pair with the PIMD usingthe identity module and allow data exchange with the PIMD if theidentity module is authorized for use. Memory is disposed in the housingthat has wireless radio firmware and medical firmware, both executableby the processor. A first radio and second radio are disposed in thehousing, where the first radio is configured to effect communicationswith the PIMD in accordance with execution of the medical firmware bythe processor and the second radio is configured to effectcommunications with a remote server via a wireless network in accordancewith execution of the wireless radio firmware by the processor. Theprocessor is generally configured to use at least the identity datastored in the identity module and execute program instructions tofacilitate authentication by the remote server prior to permittingaccess to the remote server and facilitate authentication of the remoteserver prior to permitting access by the remote server.

In yet another embodiment, a method for effecting communications betweena patient communicator and a PIMD and for facilitating communicationsbetween the patient communicator and a remote server via a wirelessnetwork is described. A paired PIMD is identified by a processor usingphysiologic data obtained from the patient, where the physiologic datais stored in an identity module of the patient communicator. Dataexchange between a patient communicator and the PIMD is prevented unlessthe identity module of the patient communicator is designated for useonly with the patient communicator. Communications are effected betweenthe PIMD and a first radio of the patient communicator in accordancewith execution of the medical firmware by the processor. Communicationsare effected between a second radio of the patient communicator and aremote server via a wireless network in accordance with execution of thewireless radio firmware by the processor. Identity data stored in theidentity module is provided to the remote server for authentication bythe remote server prior to accessing the remote server, and the remoteserver is authenticated using the identity data stored in the identitymodule prior to permitting access by the remote server. PIMD databetween the patient communicator and the remote server is exchanged inresponse to successful authentication.

According to various embodiments, a portable patient communicator (PPC)is configured to communicate with a patient implantable medical device(PIMD) and facilitate communications with a remote server via a wirelessnetwork. The portable patient communicator, according to variousembodiments, includes a housing configured for portability by anambulatory patient. An identity module is provided in the housing and isconfigured to store at least identity data that uniquely identifies thePPC or the patient. A processor is coupled to memory and the identitymodule, and the processor and memory are provided in the housing. Thememory stores wireless radio firmware and medical firmware. The medicalfirmware is executable by the processor to facilitate interactionbetween the PPC and the PIMD in accordance with predetermined medicaldevice guidelines.

A first radio is provided in the housing and configured to effectcommunications with the PIMD in accordance with program instructions ofthe medical firmware executable by the processor. A second radio isprovided in the housing and configured to effect communications via achannel of the wireless network, preferably via a channel other than avoice channel, in accordance with program instructions of the wirelessradio firmware executable by the processor. A power source is providedin the housing and configured to supply power for components of the PPC.The processor is configured to use at least the identity data stored inthe identity module and execute program instructions for one or both of(a) facilitating authentication of the PPC by the remote server prior topermitting PPC access to the remote server, and (b) facilitatingauthentication of the remote server by the PPC prior to permittingaccess to the PPC or the PIMD by the remote server or other devicecommunicatively coupled to the wireless network.

In accordance with other embodiments, a portable patient communicatorincludes a housing configured for portability by an ambulatory patient.An identity module is provided in the housing and is configured to storeat least identity data that uniquely identifies the PPC or the patient.A processor is coupled to memory and the identity module. The processorand the memory are provided in the housing. The memory stores wirelessradio firmware and medical firmware. The medical firmware is executableby the processor to facilitate interaction between the PPC and the PIMDin accordance with predetermined medical device guidelines.

A first radio is provided in the housing and configured to effectcommunications with the PIMD in accordance with program instructions ofthe medical firmware executable by the processor. A second radio isprovided in the housing and configured to effect communications via thewireless network in accordance with program instructions of the wirelessradio firmware executable by the processor. A power source is providedin the housing and configured to supply power for components of the PPC.The processor is configured to use at least the identity data stored inthe identity module and execute program instructions for (a)facilitating authentication of the PPC by the remote server prior topermitting PPC access to the remote server and (b) facilitatingauthentication of the remote server by the PPC prior to permittingaccess to the PPC or the PIMD by the remote server or other devicecommunicatively coupled to the wireless network.

According to further embodiments, methods of the present invention aredirected to effecting communications between a portable patientcommunicator and a patient implantable medical device, and forfacilitating communications between the PPC and a remote server via awireless network. Methods of the present invention involve providing aPPC having a housing configured for portability by an ambulatorypatient, the housing supporting a processor coupled to memory forstoring medical firmware and wireless radio firmware, first and secondradios, a processor, an identity module, and a power source. Methodsinvolve effecting communications between the PIMD and the first radio ofthe PPC in accordance with program instructions of the medical firmware,and effecting communications between the second radio of the PPC and thewireless network in accordance with program instructions of the wirelessradio firmware. Methods further involve authenticating, using datastored in the identity module, the PPC by the remote server prior topermitting PPC access to the remote server, and authenticating, usingdata stored in the identify module, the remote server by the PPC priorto permitting access to the PPC or the PIMD by the remote server orother device communicatively coupled to the wireless network. Methodsalso involve exchanging at least PIMD data between the PPC and theremote server in response to successful authentication.

The above summary of the present invention is not intended to describeeach embodiment or every implementation of the present invention.Advantages and attainments, together with a more complete understandingof the invention, will become apparent and appreciated by referring tothe following detailed description and claims taken in conjunction withthe accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1A is a system diagram of a life critical network implementation inaccordance with embodiments of the present invention;

FIG. 1B illustrates an exemplary automated or advanced patientmanagement environment supported within a life critical network inaccordance with embodiments of the present invention;

FIG. 2A illustrates a patient implantable medical device configured tooperate in various frequency bands or channels for communicating with aportable patient communicator in the context of a life critical networkin accordance with embodiments of the present invention;

FIG. 2B illustrates a multiplicity of patient implantable medicaldevices that communicate via a life critical network comprising one ormore mobile and data networks in accordance with embodiments of thepresent invention;

FIG. 3 is a message flow diagram illustrating one manner of usingacknowledgment messages to verify the source of an SMS messagecommunicated between a remote server and a portable patient communicatorvia a life critical network in accordance with embodiments of thepresent invention;

FIG. 4A illustrates a multiplicity of PIMD-PPC pairs and an APM serverin a life critical network in accordance with embodiments of the presentinvention;

FIGS. 4B-4F illustrates various methodologies for performing pairing asbetween PIMDs and PPCs in accordance with embodiments of the presentinvention;

FIG. 5A shows an embodiment of a PPC equipped with one or more sensorsconfigured to sense a physiological parameter of the patient inaccordance with embodiments of the present invention;

FIG. 5B is a flow diagram illustrating acquisition of physiological datafor a particular parameter using sensors and/or circuitry on or in thehousing of a PPC in accordance with embodiments of the presentinvention;

FIG. 6 is a flow diagram illustrating an exemplary set of interactionsthat may occur between the patient and the PPC, the APM server, andother services accessible via the PPC in accordance with embodiments ofthe present invention;

FIGS. 7A and 7B are process flow diagrams describing various processesfor performing a remotely initiated and controlled capture thresholdtest using an APM server and a PPC in accordance with embodiments of thepresent invention;

FIG. 7C is a process flow diagram showing a method for remotelyprogramming a PIMD in accordance with embodiments of the presentinvention;

FIG. 8 illustrates a PPC having a reduced feature set and a relativelysmall form factor in accordance with embodiments of the presentinvention;

FIG. 9A shows an illustration of a multiplicity of PPCs communicativelycoupled to an APM server via a network in accordance with embodiments ofthe present invention;

FIG. 9B is an illustration of dashboard diagnostics accessible to localand remote users in accordance with embodiments of the presentinvention;

FIG. 10 illustrates a PPC configured with a reduced feature set, andvarious generic network access devices whose user interface capabilitiescan be exploited to expand the user interface features of the PPC inaccordance with embodiments of the present invention;

FIG. 11 illustrates various types of PIMD data that can be transferredfrom a PIMD to a PPC, from the PPC to an APM server, and from the APMserver to the clinician or other user in accordance with embodiments ofthe present invention;

FIGS. 12A-12C show various data and reports that may produced usingmedical information transported over a life critical network inaccordance with embodiments of the present invention;

FIG. 13 shows a PPC configured to provide enhanced functionality by useof detachable or configurable modules in accordance with embodiments ofthe present invention;

FIG. 14 shows a base station or hub that is configured to physically andelectrically receive a PPC in accordance with embodiments of the presentinvention;

FIG. 15 is a high level software architectural overview that shows therelationships between various LCN tasks and the events and informationthat flow between these tasks in accordance with embodiments of thepresent invention;

FIG. 16 shows the layering of functional blocks within a PIMDcommunications protocol stack in accordance with embodiments of thepresent invention; and

FIG. 17 shows server communications in functional block diagram form inaccordance with embodiments of the invention.

While the invention is amenable to various modifications and alternativeforms, specifics thereof have been shown by way of example in thedrawings and will be described in detail below. It is to be understood,however, that the intention is not to limit the invention to theparticular embodiments described. On the contrary, the invention isintended to cover all modifications, equivalents, and alternativesfalling within the scope of the invention as defined by the appendedclaims.

DESCRIPTION OF VARIOUS EMBODIMENTS

In the following description of the illustrated embodiments, referencesare made to the accompanying drawings forming a part hereof, and inwhich are shown by way of illustration, various embodiments by which theinvention may be practiced. It is to be understood that otherembodiments may be utilized, and structural and functional changes maybe made without departing from the scope of the present invention.

Systems, devices or methods according to the present invention mayinclude one or more of the features, structures, methods, orcombinations thereof described herein. For example, a device or systemmay be implemented to include one or more of the advantageous featuresand/or processes described below. It is intended that such a device orsystem need not include all of the features described herein, but may beimplemented to include selected features that provide for usefulstructures, systems, and/or functionality.

A life critical network of the present invention is preferablyconfigured as a robust network supported by existing mobile and datanetworks, and exhibiting heightened communication attributes such asguaranteed delivery, high quality of service (QoS), and tight security.A life critical network implemented in accordance with the presentinvention provides for the acquisition of physiologic and contextualdata acquired for any number of patients that are each carrying aportable communications device, referred to herein interchangeably as aportable patient communicator (PPC) or patient communicator (PC).

Acquisition of physiologic data by a remote server of the life criticalnetwork for individual patients may advantageously occur on anunscheduled basis, such as in response to predefined events (e.g.,tachycardia events) or in response to patient initiated interrogations.In this regard, a life critical network may acquire patient data for anynumber of patients that carry a PPC on an event-driven basis, incontrast to a time-scheduled basis.

Remote server acquisition of patient physiologic data may occur whilethe patient is ambulatory, such as during daily routines at the home oroffice, or when traveling locally, nationally or worldwide. Physiologicdata for patients may be acquired by a wide variety of sensors,including external and internal sensors. For example, an implantablemedical device, such as a pacemaker or ICD, may acquire physiologic dataand transmit such data to the PPC.

Data acquired by the PPC may be transmitted to a remote server of thelife critical network in real-time, such as by use of a real-time datastreaming protocol. Store-and-forward data transfer protocols may alsobe employed, such as for less critical data or when a real-time datatransfer connection is not available. Incremental data transfers mayalso be performed to reduce the volume of data transferred from the PPCto the remote server. A life critical network of the present inventionprovides connectivity between a patient's PPC and remote server that canbe dynamically adjusted to meet the needs of the patient, physician,emergency services, and system/technical personnel.

Real-time transfer of patient physiologic data may be triggered byreal-time clinical events detected by a sensor or implantable medicaldevice provided with the patient. Data transfers may also be triggeredin accordance with query/response protocols. Clinical alerts for highrisk patients may be communicated through the life critical network inreal-time. Physiologic monitoring for remote triage may be implementedin real-time through the life critical network.

Examples of patient data that may be transferred from the PPC to theremote server include electrograms (EGMs), clinical event data, episodecounters, alerts, device or sensor settings, battery status, leadmeasurements, and patient activity level, among other types of data.Data transferred from the PPC to the remote server may be integrated ata web site supported by the remote server and displayed at a remotelocation (e.g., physician's office).

Notification of data delivery and/or alerts from the PPC to thepatient's physician, an EMT or patient advocate, for example, may beimplemented by a telephone call from the life critical networks service,a fax, email or SMS message, among other modes of communication. Otherforms of patient/server interaction facilitated by the life criticalnetwork include medication management and remote interrogation orprogramming of the sensor or implantable medical device.

A PPC implemented in accordance with the present invention facilitatesacquisition of patient sensor or implantable medical device data by aremote system for ambulatory patients. A PPC of the present invention ispreferably configured to communicate wirelessly over existing mobile anddata networks, and to effect local wireless communication with one ormore internal and/or external physiologic sensors, ambient and/orcontextual sensors, implantable medical devices, and/or other externalsystems or devices.

A PPC of the present invention may be implemented to provide a widespectrum of capabilities and functionality. For example, the PPC may beconfigured to provide only a limited number of features, such as in thecase of a PPC having a reduced feature set. By way of further example, aPPC may be implemented to provide a variety of features and capabilitiesthat enable a wide range of functionality.

A PPC implemented in accordance with embodiments of the presentinvention may be dynamically configurable via interaction with a remoteserver of a patient management system and/or an implantable medicaldevice or system. Dynamically altering the configuration of a PPC servesto enhance cooperative operation between the PPC, implantable medicaldevice/sensor, and networked patient management system, referred toherein as an advance patient management (APM) system or server.Dynamically altering the configuration of a PPC may also serve toconserve power of the implantable medical device or sensor(s) that arecommunicatively coupled to the PPC.

A life critical network coupling a patient implantable medical device(PIMD) with an APM server via a PPC provides the opportunity forincreased interaction between the patient and various network componentsand services. Mobile cellular connectivity of the portable communicationdevice facilitates a variety of interactions between the patient and theAPM system, between the patient and the PIMD-PPC pair, and/or betweenthe patient or PIMD-PPC pair and other services accessible via themobile cellular network.

Exemplary services that may be provided through use of the PIMD-PPC pairinvolve medication management for the patient, medication schedulecompliance tracking, exercise schedule compliance tracking, and/orperiodic physiological test compliance tracking, compliance tracking ofprescribed external therapies (e.g., patient use of CPAP or oxygentherapies), prescription refills, and/or information relayed to thepatient's physician, patient advocate or APM server if patient activity,exercise or physiological tests indicate a change that needs attention.

The PPC and/or server may generate reminders to the patient to performsome action, such as taking medication, perform a home-based diagnostictest, exercise, or use an external therapy device. The patient remindersmay be based on a particular time schedule or may be event-driven basedon the physiological condition of the patient. A physician monitoringthe patient may prescribe the regimen of exercise (e.g., exercisefrequency or duration), and other types of activities, including thoselisted above, for example, and the patient reminders may be based onpatient compliance with the prescribed regimen.

The functionality provided by reminder schedules, medication schedule oractivity tracking may provide incentives for a patient to staycommunicatively coupled to the network, allowing for a higher level ofcare.

The ability of the PIMD-PPC pair to provide event-driven updates,real-time waveform viewing and nearly instantaneous command access tothe PIMD for modifying device parameters facilitates remoteinterrogation, testing, and PIMD programming through the life criticalnetwork.

Embodiments of the invention contemplate the involvement ofapplication-specific network solutions, as well as exploiting existingand future network technologies. Patients are equipped with a PPCcapable of carrying out wireless communications over existing datanetworks. Device and network attributes can also be modified and/orcontrolled to provide a “life critical network” by which thecommunication of vital patient information can approach guaranteed,secure delivery.

It may be unnecessary, impractical or otherwise undesirable to restrictpatients to physical areas where equipment is located to facilitateinformation communication with patient management services. In manycases, the patient's condition or health does not restrict the patientfrom normal daily activities, or at least from activities that wouldseparate the patient from fixed equipment used to communicate withpatient management services. Solutions provided by the invention advancepatient mobility by enabling wireless communication of data, commandsand/or other information between patient devices and patient managementsystems. By furnishing the patient with such mobile communicationequipment, communication can be effected periodically orsemi-continuously, at any needed time or place.

FIG. 1A is a system diagram of a life critical network implementation inaccordance with embodiments of the present invention. The networkimplementation shown in FIG. 1A includes multiple components linkedtogether to provide a specialized network that guarantees secure andtimely delivery of data that are transmitted over one or more networksand attempts to meet specific context sensitive criteria on delivery ofthat data.

The life critical network 200 essentially provides a private networkthat is configured to operate on top of existing mobile and fixedfacility networks. The LCN 200 utilizes a secured architecture providingfor authentication and management of those components that are allowedaccess to the network 200. Such components or nodes include, forexample, portable patient communicators 14, patient sensors 17A-17B,PIMD programmer systems 23, clinician mobile devices 25, clinicianworkstations 27, patient advocate mobile devices 21, and smart hubs 19,among others.

The LCN 200 preferably follows cryptographic best practices with regardto confidentiality, integrity, and availability. Given thecomputational-versus-power requirements, the LCN system 200 can minimizethe number of asymmetric cryptographic operations in favor of asymmetric algorithm based on various factors, including a knownshared-secret generated or installed at time of manufacture, and adynamically shifting key based on a seed fed to a pseudo random numbergenerator (e.g., such as model, serial number, and network time).

The LCN system 200 preferably leverages the physical network as avirtualized transport, essentially treating any underlying protocol aspotentially unsecured, and thus not relying on any native securitymechanisms inherent in any given protocol with regard to the encryptionand integrity of its data. The LCN system 200 preferably supports bothstateful and stateless connections in order to facilitate asynchronouscommunication where network bandwidth does not support real-timecommunication.

The LCN 200, as shown in the embodiment of FIG. 1A, employs a centralauthority 16 to manage access to the network infrastructure. Thisinvolves cryptographically validating and authenticating content from apotential node prior to allowing access, and performing other controlaspects of policing the network infrastructure. The LCN 200 preferablysupports the concept of classification of nodes on the network 200 intoa specific hierarchy of access abilities. The various entitiesrequesting access to the LCN 200 are granted different access rightsbased on their classification. For example, a low-urgency sensor device17A-17B may not be given access to high-speed connectivity if it isclassified in a lower urgency or priority tier. A patient implantablemedical device programming system 23 may be granted priority access to ahigher speed connectivity capability due to its more demanding need fortimely interconnection to the infrastructure. This classification andprioritization is preferably dynamically managed via the centralauthority 16.

One aspect of creating and maintaining an LCN 200 in accordance with thepresent invention is the ability to dynamically map the availableconnectivity options between nodes in the network 200. This process is akey capability to providing the optimum resources for the networkinfrastructure as well as defining various profiles for communication.

The process of mapping the environment at the source end of the network200 begins by the source agent performing a series of queries and/orconnection attempts via various methods to build potential temporal andspatial profiles. In various embodiments, the device performing themapping may employ multiple forms of both wired and wirelesscommunications. The communication mechanisms may include, but are notlimited to, the following: RF Wireless Transceivers (WiFiMax, IEEE802.11a/b/g/n, etc.); Cellular Network Transceivers (GSM, EDGE, GPRS,CDMA, etc.); Bluetooth (high or low power methods); Zigbee (IEEE802.15.4); Wired Ethernet (IEEE 802.3); Plain Old Telephone System(POTS)/Public Switched Telephone Network(PSTN); Emergency Systems (e.g.,911, WPS); TDD, SMS, MMS, EMS, and VOIP, among others.

The mapping determines the most efficient and most reliable connectionoptions that are present in the current location of the source device.Because network connections are not always stable, the mapping processattempts to survey all of the currently available connection options. Aprofile maintains these options and lists various attributes of theconnectivity methods found. These attributes could, for example, includethe following: signal type; signal strength; provider name; preferrednetwork provider information; encryption options available; andcompression options available, among others.

Once the environment has been mapped, the measured results are thenprioritized into a list of connection options of the highest bandwidth,with the most robust and secure option first on the list and thendescending towards less secure and robust options. Not all options areavailable or viable in a specific environment. As a result, the list ispopulated with only those connections that meet the requiredconnectivity requirements.

The mapping agent has the capability for creating and managing multipleprofiles per user per device. The ability to create different profilesbased on the patient location allows the LCN nodes the ability to havemultiple sets of connection options that are dynamically selected basedon the location of the patient. The decision to create a new profile canbe autonomously decided by the source user device due to the devicesensing a new location/environment for a specified timeframe or viadirect interaction with the user. Many types of environments may existfor the user—at the users residences (e.g., home, office, hospital,etc), at a mobile location (e.g., transit options including car, rail,planes, marine, etc.).

The LCN system 200 may employ a peer-to-peer or ad hoc network profile,where devices brought within range of one another may elect to leveragea profile of the other device in order to pass information up to thesystem, in particular sensors may utilize a node hopping approach. Thecondition where there are no viable connectivity options available isrealistic, so in this case the source device preferably has means(electronic or non-electronic) of conveying some aspect of the lack ofconnectivity to the user directly. This may be via various physicalmeans including but not limited to vibration, lighting an indicator,audio outputs, etc.

The connection between LCN nodes, once established, is used to transferdata securely between a source and a target. In various embodiments, thesource end represents a medical device that is used to communicate dataand diagnostic information from other medical devices in a patient'senvironment. These data may originate from medical devices taking theform of implantable medical devices (ICD, CRT-D, pacemakers, etc.), orsensor devices both external to the patient (e.g., a weight scale or ablood pressure monitor) and implantable sensors (e.g., pressure sensors,blood chemistry, temperature, etc).

These data components have varying attributes associated with them,specifically, the basic attributes of size and context. However, therealso is a concept of urgency/priority. The source component can providethis urgency/priority as a guide for determining how data is transmittedvia the LCN 200. For example, if the data retrieved was of high urgencyand criticality, the source component could use a higher performingtransmission capability of the LCN 200 to ensure that the urgent contentis sent to the target in the most efficient way. This concept would alsobe used as part of the prioritization as to how the LCN profile would betraversed.

The target component commonly is a computer system that provides theability to store the retrieved content sent from the source. The use ofthe LCN 200 enables two-way communication between the source and targetnodes. The data content being sent from the target to the source canhave many contexts. Specifically, the data could contain configurationinformation for a node or software updates, as well as any systemconnectivity updates (e.g., protocol updates, network infrastructureupdates, approved provider lists, etc.)

Alternative methods for data transmission over the LCN 200 may involvedata parsing based on criticality of data or multicasting data viaseveral channels at once. According to some embodiments, the sourcenodes in the LCN system 200 may choose to parse data into variouscategories based on urgency and use different methods based on thecategorization. An example of this capability involves a required dataupload for a medical device where the raw medical device data is sentvia fast communication channels, and statistical information may be sentalong a slower, less urgent communication channel. This capabilityallows the source node the ability to tailor use of the LCNinfrastructure 200 due to business needs, while still maintaining thecritical aspects of the medical device content.

According to other embodiments, there may be conditions where urgentcontent needs to be sent to a target and the sending node sends thecontent across multiple communication methods to assure that the data isreceived by the target node. This allows the target to receive the datafrom multiple methods and reconstruct the message if partial messagesare received.

Automated patient management involves numerous activities, includingremote patient management and automatic diagnosis of the device and/orpatient health. FIG. 1B illustrates an exemplary automated or APMenvironment 10 supported by the present invention. Each patient 12A,12B, 12C, 12D involved with the APM environment is associated with oneor more data sources or medical devices 13 (hereinafter medical devices)associated with that patient. These medical devices 13 include, forexample, medical therapy devices that deliver or provide therapy to thepatient 12A, medical sensors that sense physiological data in relationto the patient 12A, and measurement devices that measure environmentalparameters occurring independent of the patient 14.

Each patient medical device 13 can generate one or more types of patientdata and can incorporate one or more components for delivering therapy,sensing physiological data and measuring environmental parameters.Representative medical devices include patient implantable medicaldevices (PIMDs) such as pacemakers, implantable cardiac defibrillators,drug pumps, neuro-stimulators and the like. External medical devices mayalso be paired with the PPC, such as automatic external defibrillators(AEDs). The medical devices may also include implantable or externalsensors. Implantable sensors include, for example, heart and respiratorymonitors, implantable diagnostic multi-sensor non-therapeutic devices,etc. External sensors may include Holter monitors, weight scales, bloodpressure cuffs, temperature sensors (e.g., digital thermometers andcutaneous temperature sensors), ECG and/or heart rate sensor, gassensors for sensing oxygen and carbon dioxide concentration via arespiratory mask, such as a CPAP mask, drug dispensers or pill counters,etc. Other types of medical, sensing, and measuring devices, bothimplantable and external (e.g., drug delivery devices), are possible.

Each patient 12A, 12B, 12C, 12D involved with the APM environment isalso associated with at least one PPC 14 capable of wirelesslycommunicating information with an APM system represented by one or moreAPM servers 16A, 16B, 16C. Each APM server may include a database 18A,18B, 18C to store information such as patient data, device/sensorconfiguration and diagnostic data, PIMD and PPC power status and usagedata, LCN connection data, and the like. The APM server arrangement maybe implemented in a single server/database 16A/18A, or may includemultiple servers and databases as depicted in FIG. 1B. Further, the APMserver arrangement may include multiple servers and associated databasesoperating substantially independently. In such a case, information maybe exchanged between any of the APM servers through information requestsand responses. Alternatively multiple servers and databases may operateas a distributed server/database system to collectively serve as asingle APM system.

Each PPC 14 is uniquely assigned to a particular patient 12A, preferablythrough a process generally referred to herein as “pairing” inaccordance with various embodiments. As used herein, pairing generallyrefers to the unique association created between the patient's PPC 14and the medical device(s) 13 associated with that patient. Wheninformation is to be transmitted between the medical devices 13 and anAPM server 16A, the PPC 14 paired with a respective medical device(s) 13serves to wirelessly communicate the information over one or morenetworks. In one embodiment, the PPC 14 communicates by way of a mobilenetwork(s) 20, such as a cellular network. A cellular network generallyrefers to a radio network made up of numerous cells generally defined bya transmitter or “base station.” Each base station provides coverage foran area defining its respective cell, and the collective cell structurethus provides radio coverage over a wider area. The mobile network(s) 20may represent any one or more known or future wireless networkingtechnologies, such as the Global System for Mobile Communications (GSM),Universal Mobile Telecommunications System (UMTS), PersonalCommunications Service (PCS), Time Division Multiple Access (TDMA), CodeDivision Multiple Access (CDMA), Wideband CDMA (WCDMA), or other mobilenetwork transmission technologies.

In one embodiment of the invention, the PPC 14 communicates wirelesslyvia a GSM network. Data may be communicated via a General Packet RadioSystem (GPRS) mobile communications network, where GPRS refers to apacket-switched service for GSM that mirrors the Internet model andenables seamless transition towards advanced generation networks.GSM/GPRS networks have further evolved to provide increased datatransfer rates over the network. For example, one embodiment of theinvention exploits the Enhanced Data rates for GSM Evolution (EDGE),which is also known as Enhanced GPRS (EGPRS). EDGE is a digital mobiletechnology that allows for increased data transmission rates andreliability, and is essentially a “bolt on” enhancement to secondgeneration GSM and GPRS networks. Further enhancements to EDGE networks,such as “EDGE Evolution,” provides even further increases in data rates,error correction and signal quality.

Data communicated between the PPC 14 and the mobile network(s) 20 isultimately communicated with the APM server 16A. As previouslyindicated, the APM server 16A may or may not be associated with one ormore other discrete or distributed server/database systems 16B/18B,16C/18C, etc. One or more data networks 22 may cooperatively operatewith the mobile network(s) 20 to facilitate data transfers to and fromthe relevant APM server 16A. For example, the illustrated data network22 may represent the Internet, which interfaces to the illustrated EDGEor other mobile network 20 to serve landline APM server systems.

The patient communication 14 communicates with a component of a cellularinfrastructure. For example, the PPC 14 may communicate with a basestation 24 via an air interface. The base station 24 represents acomponent of the wireless network access infrastructure that terminatesthe air interface over which subscriber traffic is communicated to andfrom the PPC 14. A Base Station Controller (BSC) (not shown) is aswitching module that provides, among other things, handoff functions,and controls power levels in each base station. The BSC controls theinterface between a Mobile Switching Center (MSC) (not shown) and basestation 24 in a GSM/GPRS or EDGE mobile network 20, and thus controlsone or more base stations 24 in the set-up functions, signaling, and inthe use of radio channels.

A BSC also controls the interface between the Serving GPRS Support Node(SGSN) 26 and the base station 24 in such a mobile network 20. The SGSN26 serves a GPRS or EDGE-equipped mobile by sending or receiving packetsvia the base station 24 at the mobile interface of the GPRS/EDGEbackbone network 28. The SGSN 26 can manage the delivery of data packetsto and from the PPC 14 within its service area, and performs packetrouting and transfer, mobility management, logical link management,authentication, billing functions, etc. In the exemplary GPRS/EDGEembodiment shown in FIG. 1B, the location register of the SGSN 26 canstore location information such as the current cell and VisitingLocation Register (not shown) associated with the PPC 14, as well asuser profiles such as the International Mobile Subscriber IdentityNumber (IMSI) of all users registered with this SGSN 26.

Another network element introduced in the GPRS/EDGE context is theGateway GPRS Support Node (GGSN) 30, which acts as a gateway between theGPRS/EDGE backbone network 28 and a data network(s) 22. For example, theGGSN 30 may serve as a gateway between the GPRS/EDGE backbone network 28and the Internet, or other data networks such as an Internet Protocol(IP) Multimedia Core associated with IP multimedia subsystems (IMS). TheGGSN 30 allows mobile devices such as the PPC 14 to access the datanetwork 22 or specified private IP networks. The connection between theGGSN 30 and the data network 22 is generally enabled through a standardprotocol, such as the Internet Protocol (IP).

In the illustrated example involving an EDGE or other GSM-based network,data from the medical device 13 is transmitted “A,” received by the basestation 24, and forwarded “B” to the SGSN 26 and GGSN 30 for delivery“C” via the data network 22 to the targeted APM server 16A. The PPC 14may first communicate via a proximity network(s) 32 such as a wirelesslocal area network (WLAN). For example, where the PPC 14 is within atransmission range of a WLAN (e.g., IEEE 802.11b/g network), the PPC 14can be configured to automatically or manually connect to the WLAN 32.Other proximity networks 32 can also be employed, such as Bluetooth,Zigbee and/or WIMAX. Such proximity networks can address connectivityissues with the mobile network 20, such as within a building wherereception can be less than optimal.

In certain configurations, networks are described herein in terms ofnode networks, although arrangement of the networks as mesh networks isequally applicable to some aspects of the life critical network.

Another embodiment involves ad hoc peer-to-peer (P2P) networking, anexample of which is depicted by the peer association 34. A peer-to-peernetwork does not involve traditional clients or servers, but rather thePPCs 14 serve as nodes functioning as both client and servers to othernodes. In this manner, a PPC 14 can use another patient's 12B, 12C PPCas a relay to the WLAN 32 or mobile network(s) 20.

The data originating at the PPC 14 may be stored and/or analyzed at theAPM server 16A, which may be further coupled to one or more clientstations 36 to perform input and output functions. Methods, structures,and/or techniques described herein, may incorporate various APM relatedmethodologies, including features described in one or more of thefollowing references: U.S. Pat. Nos. 6,221,011; 6,270,457; 6,277,072;6,280,380; 6,312,378; 6,336,903; 6,358,203; 6,368,284; 6,398,728; and6,440,066, which are hereby incorporated herein by reference.

The mobile network 20 can further facilitate data or command transferfrom the APM server 16A to the PPC 14. Data can be transferred inreverse sequence (“C,” “B,” “A”). Other channels may additionally oralternatively be used. For example, one embodiment involves sendingcommands from the APM server 16A to the PPC 14 using messaging servicessupported by the mobile network 20 and data network 22 infrastructures.These messaging services include, for example, Short Message Service(SMS), Enhanced Messaging Service (EMS), Multimedia Messaging Service(MMS), etc. These messaging technologies represent “store-and-forward”message services. For example, the APM server 16A may send “D” an SMSmessage that is received by an SMS Center (SMSC) 38 that provides thestore-and-forward functionality, and is responsible for delivering “E”the message(s) to the base station 24 for ultimate delivery “F” to theaddress of the targeted PPC 14. The SMSC 38 stores the message until thePPC 14 is available, at which time it forwards the message, removes itfrom the SMSC 38, and notifies the APM server 16A that the message hasbeen forwarded. Issuing commands from the APM server 16A to the PPC 14using SMS is described more fully below.

MMS, also based on the store-and-forward service model, is similar toSMS in the manner that messages are communicated. However, unlike SMS,MMS is not limited to text messages. The destination address used in anMMS message may be the recipient's public number such as the MobileStation Integrated Services Digital Network Number (MSISDN), or may bean e-mail address. Therefore, to minimize the chance of the PPC 14receiving an SMS from an inadvertent source, a lengthy or otherwiseunique e-mail address can be contrived and used as the destinationaddress at the PPC 14. To minimize the risk of misdirected messages,messaging techniques such as those described herein may be combined withcryptographic authentication mechanisms to ensure that the PPC doesn'tattempt to process and an erroneous message.

It may be desirable, for example, to use a store-and-forward datatransfer protocol for less critical data and/or for performingincremental data transfers to/from a server. Use of a store-and-forwardtransfer protocol may be performed to reduce the volume of datatransferred from the PPC to the remote server, yet provide sufficientconnectivity between a patient's PPC and remote server.

For example, particular blocks of medical device data of interest may beselectably transferred from the medical device 13 to the PPC 14 inresponse to command signals generated by the remote server, PPC 14 ormedical device 13. Generation of these command signals may result fromprogrammed instructions residing in a memory of the PPC 14 or themedical device, execution of which may be triggered by the PPC 14,medical device or remote server. The programmed instructions may bemodified by the physician, typically via the remote server or by aninterface to the PPC 14 or medical device.

The physician may be interested in receiving arrhythmia (e.g., atrial orventricular tachyarrhythmia) related data whenever such event occurs,for example. This selected sub-set of data is tagged for transfer to thePPC 14 in accordance with the physician's request. Depending on theseverity of the event type, the physician may have requested that theevent data be automatically transferred to the remote server via the PPC14 immediately when the event occurs, or, for less serious events, betransferred the next time the PPC 14 connects with the remote server.The PPC 14, prior to establishing communications with the medicaldevice, may be programmed to connect with the remote server anddetermine if and what specific information is to be acquired from themedical device. This inquiry by the PPC 14 may be performed immediatelyprior to connecting with the medical device or at some other time (e.g.,at off-peak hours or during “cheap” connection times).

The PPC 14 may be programmed to require particular information from themedical device and/or remote server. Various implementations allow thePPC 14 to acquire particular information when needed. For example, thePPC 14 may initiate a real-time interrogation of the medical device,such as by commanding the medical device to wake-up (if applicable) andtransmit (or acquire the requested information for transmission) to thePPC 14. The PPC 14 may be programmed to establish communications withthe medical device in accordance with a pre-programmed schedule (whichmay be alterable by the remote server, medical device, or medical deviceprogrammer/interrogation device). Alternatively or in addition,connectivity between the medical device and the PPC 14 may beestablished in response to a remote command, such as a command generatedin response to patient-actuated button on the PPC 14.

The remote server may be programmed to require particular informationfrom the medical device and/or PPC 14. Various implementations allow theremote server to acquire particular information when needed. Forexample, the remote server may initiate a real-time interrogation of themedical device via the PPC 14, such as by commanding the PPC 14 towake-up the medical device (if applicable) and transmit or acquire therequired information for transmission to the remote server via the PPC14. This scenario is generally reserved for important data, as commandedmedical device wake-up and data transfer operations expend energy storesof the medical device. For less important data requests, the remoteserver may transmit a data acquisition command to the PPC 14 that is tobe executed the next time the PPC 14 communicates with the medicaldevice. In this scenario, an unscheduled or commanded wake-up and/ordata transmission operation can be avoided. A tiered connection strategymay be employed to effect communications between the remote server,medical device, and PPC 14 that is dependent on a number of factors,including severity of a patient event, power consumption, status ofcommunication link(s) (e.g., availability, quality of service, cost ofservice), physician/remote server needs, among others.

Upon detection of a physiologic or other event (e.g., arrhythmicepisode), selected blocks of data about the event may be selected fortransfer to the PPC 14. The selected data blocks typically include dataacquired by the medical device during the event, and may be specified toinclude data temporally surrounding the event that is stored in themedical device's memory (e.g., data stored in a circular bufferrepresenting data acquired n seconds before the event and m secondsafter). Histogram, event counter, alerts, and related data may also betransferred in connection with the detected event.

With a constant or quasi-constant “live” connection with the remoteserver, it is possible to determine what event data for a given patientis presently stored on the server so that collection of duplicative datafrom the PPC 14 and/or medical device is reduced or eliminated. Forexample, a patient's implanted medical device (e.g., CRM device) may beinterrogated at a clinic by use of a programmer. Prior to transferringdata from the implanted medical device, a cross-check can be madebetween the remote server (via the programmer connected thereto) and theimplanted medical device to determine whether data residing in theimplanted medical device's memory had previously been transferred to theremote server using the PPC 14. If so, the duplicative data need not bere-transferred to the programmer, thereby conserving implanted medicaldevice energy that would otherwise be expended to transmit the redundantdata.

It should be recognized that the present invention may utilize mobilenetworks 20 other than GSM-based systems. For example, the UniversalMobile Telecommunications System (UMTS) is a 3G mobile technology thatmay in the future, and in some instances currently, replace GSM/GPRSnetwork infrastructures. UMTS has a different air interface than GSMthat can be connected to different backbone networks such as theInternet, ISDN, GSM or other UMTS networks. The PPC 14 can be configuredto communicate via a UMTS network or any other existing or futurenetwork.

In one embodiment the system is configured to operate on multiple mobilenetworks. For example, the air interface of UMTS is not compatible withGSM. As depicted in FIG. 2A, the PPC 14 can be configured as a dual-modedevice capable of switching between, for example, an EDGE network 20Aand a UMTS network 20B. If a patient equipped with a PPC 14 travels toan area without a first network coverage, the PPC 14 can switch to asecond network. The PPC 14 can be configured to switch between a greaternumber of network infrastructures as well.

In the illustrated embodiment of FIG. 2A, the PPC 14 may ordinarilycommunicate data with the APM server 16A via a GSM/EDGE network 20A. Ifthe patient moves to an area having only UMTS coverage, the PPC 14 canswitch to the UMTS network 20B. In other embodiments networkcompatibility can be handled at the network level based on, for example,what is contained in the data communicated between the PPC 14 and theAPM server 16A. Determination of which network is available can beaccomplished in various manners, including determining what country orregion the PPC 14 is in based upon the base station signal.

Multiple communication channels may also be provided between the medicaldevice and the PPC. A patient implantable medical device is representedby PIMD 13 in FIG. 2A, which may communicate with the PPC 14 via variouscommunication channels. The PIMD 13 or other medical device maycommunicate using the Medical Implant Communication Service (MICS),which is a reserved frequency band between 402-405 MHz. Other frequencybands may alternatively be used, such as the Industrial, Scientific andMedical (ISM) radio band, the Short Range Devices (SRD) radio band orothers.

FIG. 2A illustrates that the PIMD 13 may be configured to operate in theISM or MICS frequency bands, or in other channels. While the PIMD 13 maybe originally configured for transmission via a single band (e.g., MICSor ISM), other embodiments enable the PIMD 13 to be configured to anappropriate transmission channel. Examples include providing aconfigurable transceiver module, or providing multiple transceivermodules respectively associated with each of the ISM or MICS (and/orother) frequency bands. The desired band may be designated throughremote commands from the APM server 16A or elsewhere. The PIMD 13 mayalso be configured to automatically switch between communicationchannels in response to a triggering event. For example, communicationbetween an PIMD 13 and the PPC 14 may switch from MICS to ISM if theMICS transceiver circuitry fails, thereby providing redundancy. The PPC14 may be configurable in a like manner. For example it mayautomatically recognize the frequency of the signal and implement theappropriate ISM, MICS, or other circuitry.

The PIMDs 13 acquire the data that is ultimately communicated to the APMserver 16A. This data varies depending on the type of medical deviceinvolved. In the case of PIMDs, examples of the acquired andcommunicated data include electrograms (EGM), events, episode counters,alerts, device settings, battery status, lead measurements, patientactivity level, and the like. Data may be provided to comply withelectronic medical record (EMR) standards. Collected data may betransferred all at once, or incrementally. Requests for data may alsoinclude data accumulated over time, such as certain data occurring on adaily, weekly, monthly, or other duration basis. The APM server 16A mayselectively request, by way of the PPC 14, particular portions of thedata stored in the PIMD or other medical device 13.

The PPC 14 is capable of communicating with the APM server 16A at anytime a connection can be made, and thus provides an “always available”functionality. In addition to scheduled data transfers, this “alwaysavailable” functionality supports event-driven data transfers that areprovided in response to an event. Such events may be based on dataanalysis results, date, time of day, monitored conditions, etc. Forexample, if a particular patient-related health event occurs, relevantdata can be immediately transmitted to the APM server 16A via the PPC14. Communication of data between the various components may becustomized for enhanced operation. Systems and methods involvingcustomized data collection for a medical device which may be useful incombination with the embodiments described herein are provided incommonly owned U.S. Patent Publication No. 20070299317, which isincorporated herein by reference.

Other examples relate to medical device 13 diagnostic or operatingconditions. One example is a low PIMD battery condition, which can besent upon its recognition. Another example is an early memory overwritewarning where a notification can be transmitted when the PIMD memory isat a particular capacity level (e.g., 90%). Yet another example isemergency ambulatory communication of critical patient data. Thenotification can be used to trigger an interrogation of the PIMD 13 toretrieve the stored data.

Embodiments of the invention also support determining what source deviceor system interrogated the PIMD 13 or other medical device. For example,the PIMD 13 can be configured to determine whether a programmer or thePPC 14 interrogated the PIMD 13. The medical device 13 can also beconfigured to record status of data transmissions, including a statusindicator(s) indicating whether certain data has already been recordedat the APM server 16A. Status may further include whether a core memorydump has been performed, or a safety core post-process.

In one embodiment the PPC 14 receives and/or transmitsdevice-independent data. Consequently the PPC 14 can operate withdifferent types or models of PIMDs 13 or other medical devices. This canbe accomplished by configuring the PPC 14 to the particular type ofmedical device 13 to which the PPC 14 is, or will be, paired. Wheninterrogating the medical device 13, the PPC 14 can send or forwardgeneric commands such as “send episodes 1-3.” This could be in the formof, for example, a style sheet. Alternatively, the PPC 14 can convertdata from any type/model of medical device 13 to a common datastructure. Data can also be compressed, either in the medical device 13or the PPC 14, or both.

Life Critical Network

One aspect of the invention involves providing a robust networkexhibiting heightened communication attributes such as guaranteed ornear-guaranteed delivery, increased quality of service (QoS), tightsecurity, etc. A network exhibiting such attributes according toembodiments of the present invention is referred to herein as a “lifecritical network” (LCN). FIG. 2B illustrates a PIMD 13 and itscorresponding PPC 14A. Any number of additional patients, and respectivePPCs 14B, 14C may also be part of the LCN 200.

The LCN 200 essentially represents a private network supported by publicnetwork infrastructure. The LCN 200 is configured to operate on top ofthe existing mobile networks 20 and data networks 22. One feature of theLCN 200 is privacy, in that only devices intended for inclusion in theLCN are allowed. Access control can be accomplished throughauthentication, which refer to procedures established to verify that thedevice requesting access to the LCN 200 is the device that it purportsto be. For example, a unique identifier(s) from the PIMD 13 may be usedas a key to authenticate the device for use on the LCN 200. A moresecure process involves specific keys and certificates programmed intothe PIMD that allow the PIMD to authenticate messages from the server.The PIMD may use its ability to authenticate the server as a way toauthenticate the PPC. A useful authentication method is the“challenge/response” approach described below.

Authentication can be further bolstered in various ways, includingencrypting the identifier, or subjecting the identifier to acryptographic hash function. A cryptographic hash function generallyuses a character string or message of any length as input, and inresponse generates a fixed-length string output often referred to as adigital fingerprint. The unique identifier of the PIMD 13 could be usedas the input. Alternatively, the PIMD 13 identifier can be concatenatedwith a unique identifier of the PPC 14, such as the Mobile StationIntegrated Services Digital Network (MSISDN) number (i.e., the “phonenumber” or other address of the mobile PPC 14) for use withauthentication processes. A cryptographic hash function may optionallybe applied to the conjoined result and used for access control. Theseand/or other security measures are employed in various embodiments ofthe invention.

Authorization processes may also be used at the PPC 14 and/or APM server16A. Authorization in this sense generally refers to functionality atthe relevant device or system that protects the device fromcommunicating unless it is granted authority to do so. Authenticationand/or authorization may use unique identifiers or certificates andcryptographic keys to determine whether device functionality(authorization) or network access (authentication) is allowed. Forexample, in one embodiment, the unique identifier(s) from the PIMD 13may be used as a key to authorize communication functionality on the PPC14.

Components of the life critical network may incorporate variousmethodologies for providing secure and reliable communication, includingfeatures described in one or more of the following references: U.S.Patent Publication Nos. 20070118188 and 20070083246 and U.S. Pat. Nos.7,218,969; 7,203,545; 7,801,620; 7,805,199; 7,218,969; 7,751,901;8,041,032; 8,027,727; and 8,160,704, all of which are incorporatedherein by reference.

The LCN 200 can provide virtual connections routed through publicnetworks 20, 22 to separate the traffic of the intended and unintendedcommunication nodes over the underlying networks. Firewalls may also beused, which provides a barrier between the LCN 200 and the publicnetworks 20, 22. These firewalls can restrict the number of open ports,specify what type of packets are passed through, and specify whichprotocols can pass. Information communicated via these restrictedchannels can further be encrypted, which involves encoding the data intoa form that only the other intended nodes of the LCN 200 can decode.Because the PPC is exposed on the cellular network, a firewall is usedto prevent unauthorized access attempts.

Embodiments of the LCN 200 aim to operate as a guaranteed deliverysystem or a near- or quasi-guaranteed delivery system. For some data andcommands between the PIMD 13 and the APM server 16A, timely delivery maybe crucial. To approach guaranteed delivery, the LCN 200 implementsmechanisms to ensure high quality of service (QoS) transmission. QoSinvolves various aspects of the connection, such as the time to provideservice, echo, loss, reliability, etc.

In addition to guaranteed delivery of data, there may be a need forguaranteed throughput for some data, such as real-time EGM or othermonitored cardiac signals. For example, data can be streamed from thePIMD 13 to the APM server 16A via the PPC 14. Streaming data over theLCN 200 can be accomplished in any known manner. Protocols such as thereal-time streaming protocol (RTSP), real-time transport controlprotocol (RTCP) and real-time transport protocol (RTP) enabletime-sensitive data to be streamed over data networks. RTP and RTCP arebuilt on the user datagram protocol (UDP), where the data is sent in aconnectionless manner in a series of data packets.

Connection-oriented protocols such as the Transmission Control Protocol(TCP) may also be used, as it utilizes acknowledgements to guaranteedelivery. While TCP may experience some loss and retransmission delays,some data loss may be tolerable depending on the data being streamed.For example, non-critical, substantially real-time EGM signals maysufficiently provide a clinician with the needed information,notwithstanding some relatively insignificant data loss or latency.Heightened QoS is also implemented on the mobile telecommunicationnetwork portion of the LCN 200.

The type of connection and manner of data transmission as between aremote server of the LCN 200, such as server 18A of the APM server 16A,and the PPC 14 may vary depending on a number of factors, including thecriticality of the data (e.g., type and criticality of physiological orother patient related data acquired from the patient's medical device,patient sensor or information manually input to the PPC 14 by thepatient; nature of a software/firmware update for the medical device orPPC 14; scheduled standard interrogation data vs. patient event/episodicor device diagnostic data; distress of the patient, such as an emergencyvs. non-emergency situation; whether data is to be pushed or pulled;geographical location of the patient/PPC 14; available communicationsinfrastructure, whether domestic or international, etc.).

In one approach, the PIMD 13 determines the criticality of the databased on the patient condition or event detected by the PIMD 13. Alook-up table of patient condition/event severity versus criticalitylevel may be established for a particular PIMD 13. For example, alook-up table stored in the memory of an ICD may categorize ventricularfibrillation as the most critical level (L1), followed by ventriculartachycardia-1 (L2), ventricular tachycardia-2 (L3), prematureventricular contractions (L4), pacemaker-mediated tachycardia (L5),atrial fibrillation (L6), atrial tachycardia (L7), supra-ventriculartachycardia (L8), premature atrial contractions (L9), etc. Each patientcondition/event can have a corresponding criticality level, it beingunderstood that two or more conditions/events can have the samecriticality level. In response to one of these or other triggeringevents, the PIMD 13 preferably transmits criticality level data, alongwith other data, to the PPC 14.

The connection attributes by which the PPC 14 connects with, andcommunicates over, the LCN 200 may be based, at least in part, on thecriticality level data received from the PIMD 13. For example, the PPC14 may be programmed to establish a real-time, high QoS connection forhigh criticality levels, while lower criticality levels may only requirea standard QoS connection. The PPC 14 may progress sequentially througha prioritized list of connection types/attributes associated with agiven criticality level, until the connection is established. For highcriticality levels, for example, the prioritized list may be organizedso that the PPC 14 progresses sequentially from most desirable to leastdesirable connection type/attributes. For low criticality levels, theprioritized list may be organized so that the PPC 14 progressessequentially from least expensive (e.g., night or off-peak hours) tomost expensive connection type/attributes.

It is noted that, in the case of a high criticality level scenario, thePPC 14 may not be able to connect with the LCN 200 (e.g., PPC 14 is inan underground area of the hospital). In such a case, the PPC 14 mayinclude a visual indicator that illuminates, flashes or provides amessage prompting the patient (or caregiver) to move to another locationso that the PPC 14 can establish a connection. The PPC 14 may also oralternatively produce an aural and/or tactile (e.g., vibratory) outputto prompt the patient (or caregiver) to move to another location so thatthe PPC 14 can establish a connection.

According to another approach, the PPC 14 determines the criticality ofthe data based on the patient condition or event detected by the PIMD13. A look-up table of patient condition/event severity versuscriticality level may be established for a particular PIMD 13 and storedin a memory of the PPC 14. As in the case of the immediately precedingexample, the connection attributes by which the PPC 14 connects with,and communicates over, the LCN 200 may be based, at least in part, onthe criticality level data determined by the PPC 14. In addition to PIMDdata, it may be desirable for one or both of the PIMD 13 and PPC 14 touse sensor data (implanted or external) to determine or modify thepatient's criticality level.

In one embodiment, the particular QoS or other network attributes canchange relative to the patient status. For example, data originatingfrom scheduled status transmissions can be communicated using a standardQoS. The QoS of transmitted data can rise as the relative criticality ofthe data or underlying condition rises. Critical data such as thattriggered by a serious cardiac anomaly can be communicated to the APMserver 16A, a hospital, an ambulance or other relevant destination usingthe highest QoS. It may be necessary or desirable to prioritize APMserver response/resources based on patient status and/or condition.Criticality of patient condition may be used as a parameter by the APMserver to determine which patients to triage first.

The criticality of a patient condition may change after an initial QoShas been determined. For example, an initial QoS or other networkattribute may be initially established based on detection of atrialfibrillation. The QoS or other network attribute may adjust in real-timeduring and/or after the atrial fibrillation episode depending on achange in the patient's status. The QoS or other network attribute maybe increased/adjusted if the atrial fibrillation accelerates or if itinduces ventricular arrhythmia, for example. Conversely, the QoS orother network attribute may be reduced/adjusted if the atrialfibrillation lessens in severity or terminates either spontaneously orvia atrial therapy delivered by an implanted CRM device, for example.This sliding scale of patient status-to-QoS provides the appropriatedelivery guarantees based on the particular circumstances.

Various QoS attributes can be controlled in order to provide anappropriate connection for transmitting medical data over the LCN 200.Various QoS attributes may be modified to change connection attributesbased on the criticality of the medical data to be transported over theLCN 200. Such QoS attributes may include traffic influencing parameters,such as latency, jitter, packet loss, bandwidth, and response time;management of finite resources, such as rate control, queuing andscheduling, congestion management, admission control, routing control,traffic protection; and service level agreement requirements for flows(e.g., flow-based or aggregated flows).

QoS service methodologies that may be made available for medical datatransport include best effort (no QoS), integrated services (hard QoS,IntServ Architecture, see RFC 1633, RFC 2205, RFC 3175), anddifferentiated services (soft QoS, DiffServ Architecture, see RFC 2475,RFC 3270) methodologies. Another network technology that allows for QoSpriority selection is referred to as MPLS (Multiprotocol LabelSwitching, see RFC 3468, RFC 3209). DiffServ, for example, can be usedto provide low-latency, guaranteed service to critical network traffic,such as transport of high criticality PIMD data, while providing simplebest-effort traffic guarantees to non-critical network traffic, such aslow criticality PIMD data, PIMD-APM server traffic, or routine filetransfers.

One approach to implementing selection and/or adjustment of network QoSattributes based on medical data criticality is to establish a mappingof QoS attributes needed to support the LCN network (e.g., a mapping ofdesired or required QoS attributes based on PIMD data criticality). ThisLCN QoS schema can be developed by the medical device manufacturer incooperation with physicians and health care entities, for example. Aschema of the public network QoS (e.g., the cellular network(s) and anyother data network(s) that are part of the LCN 200) may be developed bythe medical device manufacturer in cooperation with the cellular andother network operators, for example. A QoS mapping of LCN QoS-to-publicnetwork QoS (e.g., for data transfers from the PPC 14 to the APM server16) and a mapping of public network QoS-to-LCN QoS (for data transfersfrom the APM server 16 to the PPC 14) may thus be developed using theLCN and public network QoS schemas.

In accordance with another approach, the LCN 200 may provide enhancedmedical data transport using a Wireless Priority Service (WPS). WPS hasbeen developed to provide priority for emergency calls made fromcellular telephones. WPS is an easy-to-use, add-on feature subscribed ona per-cell phone basis, with no special phone hardware required. WPS isimplemented as software enhancements to existing cellular networks, andis being deployed by cellular service providers in their coverage areasthroughout the United States.

WPS provides priority for emergency calls through a combination ofspecial cellular network features. WPS addresses congestion in the localradio access channel (or cell), which is often the reason that cellularcalls cannot be made during heavy calling periods or when damage tonetwork infrastructure occurs. WPS automatically provides priorityaccess to local radio channels, placing WPS calls in queue for the nextavailable channel if a channel is not immediately available. OriginatingRadio Channel Priority requires WPS feature activation on the callingcellular phone. WPS calls do not preempt calls in progress.

When a radio access channel becomes available and the call proceeds, WPScalls are assigned a unique call marking by the cellular networkswitching equipment. This marking triggers industry standard HighProbability of Completion (HPC) features residing in most U.S.telecommunications networks as calls are routed from the originatingcell to the called cellular or landline phone. These HPC featuressignificantly increase the probability of call completion should thecall encounter network congestion or blockage beyond the originatingcell.

Access rights of a PPC 14 to connect to the Wireless Priority Servicemay be established by medical device manufactures and local and nationalgovernmental agencies. The connection attributes or rights by which thePPC 14 connects with, and communicates over, a WPS connection of the LCN200 is preferably based on criticality level data received from the PIMD13. For example, the PPC 14 may be authorized to establish a WPSconnection for high criticality levels, while lower criticality levelsmay not qualify for a WPS connection.

As described above, commands may be sent from the APM server 16A to thePPC 14 using messaging services supported by the mobile network 20infrastructure. One embodiment of the invention involves using ShortMessage Service (SMS) or “text messages” to direct commands to the PPC14 for ultimate delivery to the PIMD 13. Verification techniques may beemployed to ensure that an SMS message from an unauthorized source isnot inadvertently addressed to the PPC 14 and perceived as a command. Inone embodiment, a subset of the data in the SMS message may be used bythe PPC 14 to verify that the SMS message originated from an authorizedsource (e.g., APM server 16A). One example involves the PPC 14 comparingthe source address (e.g., MSISDN number) of the SMS message with astored list of approved source addresses. In another exemplaryembodiment a code may be inserted into the SMS message itself Forexample, a standard SMS message supports 160 characters, and the firstpredetermined number of characters may represent a code used by the PPC14 to verify that the sender is genuine. The code may be theconcatenated PIMD/PC identifiers signed with the APM server's privatekey. The APM server's private key can be verified by both the PPC andthe PIMD as they have the public key for the server in their set ofcertificates.

Message verification techniques utilizing handshaking may also be used.FIG. 3 is a message flow diagram illustrating one manner of usingacknowledgment messages to verify the source of the SMS (or other)message. Such a handshaking embodiment enables the PPC 14 to verify thatthe command originated at an APM server 16A or other authorized sourcebefore forwarding the command to the PIMD 13. This may be beneficial,for example, where the PPC 14 is unaware of the APM server 16A sourceaddress. The PPC 14 may be generally unaware of APM addresses, or newAPMs having new source addresses may be added to the system unbeknownstto the PPC 14.

Operationally, the APM server 16A may direct a command to the PPC 14 viaan SMS-based command 300. If the APM server 16A was in fact the sourceof the SMS message, it enters a wait state 302 or otherwise notes thatit has initiated the message. The command is forwarded through the dataand mobile networks 22, 20, and arrives at the PPC 14. Rather than“reply” to the source address of the incoming SMS message, the PPC 14inserts 304 a known APM address as the destination address. Thus, evenif the SMS message originated at an unauthorized source, the resultingacknowledge message (ACK) 308 is directed to the APM server 16A.Additionally, the sender's address (i.e., the source address identifiedin the received SMS message) can be included 306 in the responsive ACKmessage, for reasons discussed more fully below.

When the ACK 308 arrives at the APM server 16A, it verifies 310 that itwas in a wait state, waiting to receive an ACK message from the PPC 14.If it was not, it can be assumed that the SMS message received at thePPC 14 was not issued by the APM server 16A, and the APM server 16A cannotify the PPC 14 as such. Further, the sender address provided by thePPC 14 in the ACK message can be compared 312 to a set of known APMaddresses, if multiple APM and corresponding APM addresses exist. If thereceived sender address does not correspond to any known APM addresses,it again can be assumed that the original SMS message received at thePPC 14 was not initiated by the APM system. If the received senderaddress matches a known APM address, the APM sends an OK 314 or otherconfirmatory message to notify the PPC 14 that the original SMS messagewas indeed issued by the APM system. Upon receipt of the OK 314 message,the PPC 14 can transmit 316 the command embodied within the SMS messageto the PIMD 13 or other medical device paired with the PPC 14.Additional or alternative processes for message verification that may beused are described in commonly owned U.S. Patent Publication No.20070185547, which is incorporated by reference herein.

When using the SMS medium, the security keys and identifiers included inthe text message need to be smaller than the character limit for SMS. Inone approach, a key that the APM server recognizes may be embedded inthe text message. A simple encryption approach may be used, whichinvolves sending medical data without patient-identifying information,and including the medical device serial number or the SIM (SubscriberIdentity Module) serial number.

Streaming data from the PIMD 13 or other medical device over the LCN 200and to the APM server 16A via the PPC 14 may be enabled and disabled ina number of ways and in response to varying conditions, triggers orevents. The manner and paths by which PIMD data is streamed over the LCN200 may be based on events or patient conditions such as criticality ofthe data, distress of the patient, and whether or not an emergency callhas been attempted via a 911 service, among others.

A PPC 14 may be programmed so that its behavior relative to the LCN 200and/or the PIMD 13 is dynamically adjusted based on predeterminedconditions. For example, if the PPC 14 detects that it is out of rangeof the PIMD 13, the “status” of the PPC 14 on the LCN 200 may be changed(e.g., reduced). The status of the PPC 14 refers to the level ofcapabilities granted a particular PPC 14 when operating over the LCN200. A PPC 14 that is out of range of its corresponding PIMD 13 may havea reduced ability to communicate with the APM server 16, such as bybeing denied access to certain functions (e.g., over-the-air PPCfirmware upgrades, PIMD interrogation or programming commands) and datathat are appropriate only when the PPC 14 is in range of its paired PIMD13.

By way of further example, use of cellular phones and devices is oftenrestricted in most areas of hospitals and health care clinics, butpermitted in lobby areas. During a hospital or clinic visit, it may bedesirable to establish communication between the PPC 14 and the LCN200/APM server 16, particularly during extended visits. Assuming thatthe patient is restricted to his or her room, a caregiver may take thePPC 14 to the lobby or other permitted area and establish a connectionwith the LCN 200/APM server 16. Granting authorization to the caregivermay involve some form of authentication, such as thumbprint, voice, orPIN code authentication, for example. The PPC 14 may be configured withappropriate hardware and software to perform this “third party”authentication, which will vary depending on the manner ofauthentication (e.g., a thumbprint reader, voice-recognition circuitry).

The present “status” of a PPC 14 may not be apparent to the patientuntil a connection with the APM serve 16 is attempted, eitherautomatically or by actuation of a manual sync button on the PPC 14 thatinitiates an upload/push data operation, for example. If the patientattempts to use the wrong PPC 14, an indication of the PPC's reducedstatus is preferably indicated in some visual, aural or tactile mannerto the patient. Although basic data may be transferred out of the PPChaving a reduced status, full uploading/functionality may only begranted to a properly paired PPC, although high priority/criticalitydata/events would likely be excepted.

Tiered functionality may be programmed into the PPC based on correct orincorrect pairing. There may be scenarios where incorrect pairing isdetected, but the location of the PPC indicates that a PPC's status needonly be minimally reduced (or not at all). Scenarios where incorrectpairing occurs, but where there is a high level of confidence that thePPC 14 is in the right location for the patient, include multiple PPCscenarios, the PPC in the office, home, clinic, physician's office orhospital, the PPC in a nursing home, and the PPC in a pharmacy (via thepharmacy's Wi-Fi that can be identified as such).

The effectiveness of the LCN 200 depends in large part on thereliability of the cellular network or networks that facilitateconnectivity between PPCs 14 and the APM servers 16. Various techniquescan be implemented to improve data transmission efficiency andreliability through the LCN 200. A forward error correction approach,for example, may be implemented by which data is re-sent multiple timesfrom the PPC 14 (e.g., data redundancy).

An approach to determining appropriate connection attributes for a PPC14 may involve determining latency of transmission between the PPC 14and the APM server 16. One approach to determining this latency is todetermine round trip time (RTT), such as by use of a ping service, whichmay be initiated by the PPC 14. In response to receiving a ping packettransmitted by the PPC 14, the APM server 15 sends back a responsepacket (i.e. performs a no-op). A ping operation does not involveperforming packet processing, so the RTT measured by the PPC 14 is arelatively accurate measure of round trip latency. The PPC 14 may beprogrammed to perform a ping operation and consider RTT when determiningappropriate connection attributes for connecting to the LCN 200.

Depending on the criticality of the data, the PPC 14 may be programmedto negotiate a higher output power from the cell tower(s) or an increasein the PPC's network interface transmission power on a temporary basis.In general, a conventional cellular phone is not permitted to adjust itsnetwork interface power output with respect to the particular celltowers over which it is presently communicating. Rather, networkinterface output power of cell phones communicating over particular celltowers is moderated by those cell towers. A cellular network operatormay cooperate with the medical device manufacturer of the PPCs 14 tooffer special services for patient subscribers that use the operator'scellular network to support the LCN 200.

These special services may include the PPC 14 negotiating a higheroutput power from cell tower(s) for transmitting critical data.Alternatively, or in addition, the cell tower(s) can raise its basepower. These special services may include adjusting the QoS fortransmitting critical data and/or change the carrier frequency to afrequency that minimizes interference with other connections. Uniqueinformation (codes or profile packets/bits) may be transmitted from thePPC 14 that indicates a request for special services is being made whichis recognizable by the cellular network operator. Based on the data'scriticality level, one or more connection attributes may be adjusted bythe cellular network operator in response to the PPC's request.

Embodiments of the invention are directed to tiered approaches forcommunicating data over a life critical network. A tiered or prioritizedapproach to communicating medical data over a network is particularlybeneficial in cases where non-ideal infrastructural conditions exist orarise, such as dead spots or undesirable tower interaction in a wirelesscommunication system, and where patient condition can vary dynamicallybetween normal and life-threatening. A tiered approach facilitatesexploitation of different communication protocols and mediums fordifferent clinical data, events, and/or priority.

According to some embodiments, the PPC 14 implements control logic todetermine the proper communication protocol and medium for exchangingdata with a remote server based on the purpose and priority/urgency ofthe data exchange and/or infrastructural status. The PPC 14 may, forexample, have different physical channels of communications available toit, such as a telephone line, cellular, Wi-Fi, etc. Not all of thesephysical channels are always available, and they have different costs,performance characteristics, and levels of service. Cellular technology,for example, allows for a number of different mechanisms for dataexchange, each with different levels of service, throughput, andpurposes (e.g., raw data, SMS, email, and others).

The PPC 14 and remote APM server 16A have many different reasons toexchange data. Data transmission from/to the PPC 14 and APM server 16Aoccurs at different frequencies, some are physician or patientinitiated, and some are medical device manufacturer initiated. Thesedata have different priorities, including urgent, nominal, or lowpriority, or even optional. The PPC 14, according to some embodiments,may be configured to determine some or more of the degree of urgency,purpose of the data exchange, the cellular network's currentcapabilities, and the transport mechanisms available.

In accordance with an illustrative example of a tiered communicationsapproach as between a PPC 14 and a remote APM server 16A, it is assumedthat the highest degree of priority or urgency is associated with anemergency or time critical situation, such as when therapy delivery isineffective or all therapies are exhausted. In such cases, the PPC 14 ispreferably programmed to utilize all communications protocols andmediums available to it. Some of these channels may be reliable whileothers may be unreliable. Parallel messages over multiple channels (datachannels, SMS, two cell towers, Wi-Fi to local network) are preferablytransmitted by the PPC 14 in an attempt to reach the APM server 16A. ThePPC 14 preferably sends the same urgent message on all the mediums.

According to one approach, the PPC 14 sets a unique identifier for themessage to be delivered on all mediums. The same identifier is used onall of the messages triggered by the same event. The APM server 16A mayreceive one or more of the urgent messages through any of the channels.The APM server 16A utilizes the unique identifier and identifies thatthe messages are the same. The APM server 16A only acts on one of themessages—acting on more than one is redundant. A unique stamp may beused to verify this is the same message, albeit received from disparatemediums.

In response to receiving the message from the PPC 14, the APM server 16Apreferably sends an acknowledgement back to the PPC 14. Theacknowledgement includes the unique identifier. When the PPC 14 receivesthe acknowledgement, it discontinues transmitting the urgent message. Ifthe PPC 14 does not receive an acknowledgement, it continues toretry/transmit the urgent message at some regular interval.

Continuing with this illustrative example, it is assumed that an alertbased on patient data represents the second highest priority or urgencylevel. A typical “red” alert indicates that there is a problem with themedical device or patient's health condition that needs to becommunicated to the APM server 16A (e.g., “Not in Monitor+Therapy Mode”alert condition). In response to an alert condition, the PPC 14 firstattempts to use the configured cellular/mobile data network interface.Using a cellular/mobile medium, the clinician receives the alert soonerthan when using a once-per-day scheduled check of the PPC 14 initiatedby the APM server 16A. If the cellular/mobile medium or other datainterface is not available, the PPC 14 attempts a more simpler form ofdata exchange, such as a store-and-forward exchange (e.g., SMS).

The third highest priority or urgency level according to thisillustrative embodiment may be for problems with the PPC 14 where thepatient is in an unmonitored state (i.e., unmonitored by the APM server16A). A problem with the PPC 14 may be detected by the APM server 16A,such as by detecting non-receipt of PPC data for a predetermined periodor failure to receive such data in accordance with a predeterminedschedule. The APM server 16A may also detect an unmonitored patientstate by pinging the patient's PPC 14 and failing to receive a responsefrom the patient's PPC 14 within a predetermined period of time. The APMserver 16A, in response to detecting loss of connectivity with thepatient's PPC 14, may attempt to establish communication with the PPC 14using all mediums and protocols available to it, preferably using atiered approach. For example, the APM sever 16A may attempt to use adata network followed by use of SMS.

The PPC 14 may detect loss of APM server connectivity using strategiessimilar to those discussed above but initiated by the PPC 14. If, afterimplementing a tiered strategy for attempting to connect with the APMserver 16A, the PPC 14 determines that such attempts have beenunsuccessful, the control logic of the PPC 14 may execute a procedure todraw patient awareness to the present problematic state of the PPC 14.The PPC 14 can, for example, flash an alert light or message on adisplay or broadcast an audible alert. Other approaches may be used,such as activating a vibrating element of the PPC 14 or other tactiletransducer. These and other methods of attracting the patient'sattention may be implemented, such as in a tiered approach based onfactors such as power consumption, likelihood of success, orpre-determined preferences established by or for the patient. Thepatient, upon detecting an alert initiated by the PPC 14, may contactthe physician or PPC manufacturer or service for assistance.

The fourth highest priority or urgency level according to thisillustrative embodiment is for data exchanges to and from a physician orclinician. Data transfers to the physician is effected in a mannerdiscussed previously with regard to implementing a tiered approach fortransferring data from the PPC 14 to the APM server 16A over the LCN200. For data transfers from the physician to the PPC 14, astore-and-forward medium or protocol is preferably used, since the PPC14 may not be presently connected to the APM server 16A. According toone approach, a physician (or r technician) preferably defines aninterrogation schedule, and the APM server 16A pushes the interrogationschedule to the PPC 14. This approach may be supplemented by scheduled(or commanded) PPC pulls from the APM server when the PPC 14 connectswith the APM server 16A.

Clinicians may push data to the PPC 14 from the APM server 16A for avariety of reasons other than, or in addition to, performing PIMD or PPCinterrogations. For example, physician directed data may be pushed tothe PPC 14 to prompt the patient to take some action, such as to takedrugs (e.g., maintain prescribed medication regimen, titrate diuretics,activate or adjust drug delivery device), take some type of measurement(e.g., weight, oxygen saturation, blood pressure, heart rate), orinteract with a sensor (e.g., blood pressure cuff, weight scale, glucosesensor), among other actions. The clinician may analyze certain data andeffect some form of communication to the PPC 14 via the APM server 16A.

The fifth highest priority or urgency level according to thisillustrative embodiment is for notifying the patient that a datatransmission failed after repeated attempts. This message class includesmessages for prompting the patient to contact the medical device companyif the PPC 14 is unable to communicate properly. A sixth highestpriority or urgency level is for performing routine interrogation of thePIMD 13.

The seventh highest priority or urgency level according to thisillustrative embodiment is for evaluating status of the PPC 14. Thismessage class consists of very low priority information that can be lostor not collected. It consists of diagnostic information not critical tothe patient, physician, or the system operation. Accordingly, a low costtransport mechanism (e.g., SMS) is preferably selected. The transmissionof low priority content may be delayed for lower cost periods of theday/night.

The manner in which a multiplicity of PPCs 14 connect with, andcommunicate over, the LCN 200 may be controlled to reduce overallnetwork usage. For example, the quantity and type of content of the datatransmitted over the LCN 200 (uni- or bi-directional) may be adjusted(increased or decreased) by the APM system operator as needed ordesired. Data content and transmission attributes may be modifiedon-the-fly for one or a multiplicity of PPCs 14, which may affect thePPC(s) 14 future behavior by causing it/them to not send as much data orto send more data, depending the need. The APM system operator may, forexample, control all PPCs 14 in group-wise fashion, such as by reducingor disabling data content transmission from the PPCs 14 or by commandingall PPCs 14 to transmit full data content with diagnostics, includingcommunicator and SIM identification data, for example.

The manner in which data is to be exchanged between the PPC 14 and APMserver 16A may be impacted at least in part by the cellularinfrastructure. For example, a message or settings may be sent from theAPM server 16A to all or appropriate cell towers that will pass themessage or settings on to one or more of the PPCs 14. The message orsettings may be delivered to the PPC(s) 14 in a variety of ways, such aspart of a normal tower-communicator cellular exchange, a queuedtransmission at off-peak hours, or as part of a PPC 14 being powered-upand setting up the cellular connection.

LCN Connection Strategies

The efficacy of a life critical network depends in large part on thecapability of the LCN to facilitate transport of critical medical data(e.g., CRM device data) over a public cellular network infrastructure ina secured and time-efficient manner. A variety of methodologies may beemployed to maintain and enhance LCN efficacy. For example, theintegrity of the communication link between the PIMD 13 and PPC 14 maybe enhanced by performing block transfers of PIMD (e.g., IPG) datasnapshots into a buffer for transfer to the PPC 14. This approach mayadvantageously avoid dropouts between the PIMD 13 and PPC 14. As wasdiscussed previously, PIMD data transferred to the PPC 14 may betransmitted over the LCN 200 in a number of ways, including a sessionbased connection or an ACK-based connection. Suitable transportapproaches include automatic retry query (ARQ), TCP, and UDP streaming,among others.

Another approach involves transmitting an urgent message orimportant/critical data to multiple cell towers, such as two towers. Themessage/data can first be transmitted to the cell tower that providesthe best signal quality followed by transmissions of the samemessage/data to the tower(s) with lower signal quality. Variations ofthis approach are discussed hereinabove.

In cases where a preferred LCN connection is not available or becomesunusable, alternative connections may be sought in accordance with apredetermined priority scheme. For example, should a preferredconnection such as a high QoS cellular connection become unavailable, aPPC 14 may attempt to connect to the LCN 200 using a data channel (e.g.,Ethernet connection), MMS, SMS, Wi-Fi, or low-speed modem over a voicechannel (to operate as a modem to transmit data), for example. If apatient has no cell coverage, intermittent coverage, or periodic (e.g.,day/night) coverage, a predetermined priority scheme may includeswitching to a Wi-Fi network as backup. The Wi-Fi is preferablypreconfigured to provide efficient connectivity between the PPC 14 andthe LCN 200. Another fallback is to attempt a connection using anynetwork that can be found by the PPC 14.

When out in public, several opportunities for connecting to the APMserver 16A may be exploited. In one approach, a public kiosk or Wi-Fiaccess point (e.g., municipal, within a store or coffee house, at apharmacy) may be used. A tiered connection and data transport strategymay be implemented in accordance with the type of connection made.

For example, a greater range of PPC functionality may be granted if thePPC 14 connects with the APM server 16A via a pharmacy or hospital'swireless access point, relative to a generic public access point.Several network service discovery mechanisms may be used by the PPC 14to facilitate discovery of available network services, including ultralow-power mechanisms (e.g., via Bluetooth). Another approach involveshopping onto another person's cell phone who is in proximity with thepatient's PPC 14. Yet another approach involves an ISM to ISM scheme,which can be a relatively long range mechanism (e.g., 200 meters) thatprovides complete control of a radio. This approach would allow the PPC14 to connect (i.e., bootstrap) to another PPC 14 or cell phone via ISMradio, and then using the cell phone for establishing a networkconnection.

According to another approach that involves a docking station or hub forthe PPC 14, a message or indicator may be communicated to the patient bythe hub or PPC 14 to dock the PPC 14 to the hub. Assuming the hub has analternative medium to connect to the LCN 200, such as POTS connection,this alternative medium can be used to connect the PPC 14 to the LCN200.

Another approach involves the PPC 14 indicating to the patient to moveto another area where coverage is available. The PPC 14 may indicate tothe patient that a message needs to be transmitted and the patientshould try to go to a known good cellular coverage area or dock theirdevice.

In cases where PPC data is collected at a scheduled time, such as duringthe night), but there is no coverage when patient is at rest, a numberof actions may be performed. A store-and-forward procedure may beimplemented when the connection becomes available. Another action mayinvolve a mechanism to notify the patient, especially is the case of anemergency (e.g., red alert) condition. If the data is not received bythe APM server 16A or the PPC 14 does not get a signal for apredetermined period of time, the patient is preferably notified (e.g.,a phone call to the patient's home, an email or SMS message to thepatient's cell phone).

Some classes of devices, as controlled by their SIM, may have higherpriority for using the cellular infrastructure, such as police, fire,and emergency medical personnel (e.g., higher priority via a WirelessPriority Service connection). During normal operation with no emergencydata, the PPC 14 preferably utilizes normal SIM settings and receivesthe commonly available cellular service. If the PPC 14 has emergencydata to be delivered, the PPC 14 preferably registers with theemergency-class SIM to utilize the special-availability class ofservice. It is important to change the emergency priority designationbased upon status to avoid always using emergency channel.

If the cellular network is full or otherwise inaccessible, the PPC 14may be programmed to re-attempt a connection at appropriate intervals,which would preferably involve attempts to connect via alternativemediums. Should the PPC 14 ultimately fail to connect to the LCN 200, amessage or indictor is preferably presented on the user interface of thePPC 14 (or broadcast via an audible message or tactile output) promptingthe patient to contact his or her physician or medical devicemanufacturer.

International travel by a patient can present a number of challengeswhen attempting to connect to the LCN 200 via the PPC 14. When travelingin an airplane or on a cruise ship, the PPC 14 is preferably programmedto connect to the LCN 200 via an airborne or shipboard communicationsnetwork. For example, the PPC 14 is preferably configured to access anairliner's cellular access point via a wireless protocol, such asonboard Wi-Fi device (e.g., AirCell 802.11a/b/g wireless access point oran 802.11 n wireless access point). A typical airborne cellular networkdeployment includes three towers mounted on the exterior of the plane,which beam to ground stations in the United States. A similar approachis employed in Europe and elsewhere. Some airlines provide Ethernet andUSB ports in each seat which can be used to provide LCN connectivity.When cruising, the patient may connect with the LCN 200 via a globalmaritime cellular operator that is accessible throughout the cruiseship. The shipborne radio networks, typically GSM or CDMA, are generallylinked to public networks via satellite.

The PPC 14 may provide the option to operate in “flight mode,” in whichthe transceiver used to connect to a wireless network is turned off. Thewireless transceiver that communicates with the PIMD may remain on ormay be switched to a short range power setting (or may be turned off aswell). The PIMD transceiver of the PPC 14 may incorporate a wake-updetection circuit that “listens” for an emergency wake-up signal fromthe PIMD. This emergency signal may be a low-power RF signal, anacoustic signal, or other signal that does not (or only minimally)interferes with onboard communications systems.

The PPC 14 may be set to “flight mode” by actuation of an appropriatebutton on the PPC 14 (or by voice command activation). A flashing lightor other indicator is preferably generated to indicate to the patientthat the PPC 14 is in “flight mode.” After the flight, the flashinglight or indicator prompts the patient to switch off the “flight mode.”Various automatic techniques may be employed to ensure that the PPC 14does not remain indefinitely in “flight mode” should the patient forgetto switch this mode to off. One approach involves using a timer, whichstarts when “flight mode” is selected, to turn off “flight mode” uponexpiration. The timer may be set to a duration that guarantees that theflight will have concluded, such as 24 hours, for example.

In the case of a PPC 14 communicating with LCN 200 via an EDGE network,the PPC 14 can have from 1 connection up to 5 connections. The number ofconnections controls the data rate. When the EDGE network is busy, thenumber of PPC connections is reduced (e.g., from 4 down to 1). The PPC14 can detect how many connections are available to it, and modify itsbehavior accordingly. The PPC 14 utilizes the EDGE and cell towerinformation to determine how much bandwidth might be available, and todetermine if the medium is appropriate for the message'spriority/urgency. This information can be included in the APM system'sdashboard diagnostics, which is discussed below.

For example, the PPC 14 may detect availability of a large number ofconnections, which allows the PPC 14 to stream data, such a real-timeEGM data, to the APM server 16A. When a reduced number of connections isdetected, the PPC 14 adjusts its data output rate and/or content toallow for data transfers at the reduced data rate. The PPC 14 preferablyrequests more bandwidth based upon urgency. The PPC 14, based on themessage priority/urgency, preferably requests the cell tower for moreEDGE channel connections. This request feature may be one of the“special services” accorded a PPC 14 as discussed previously.

Dashboard Diagnostics/Interfaces

The physician or other authorized person may interact with the APMserver to access a variety of information concerning a particularpatient, the patient's medical device, and/or the PPC. FIGS. 9A and 9B,for example, show a user access device, such as a laptop or PPC 835,that provides authorized access to an APM server 850 via a network 830(e.g., LCN). The laptop 835 may reside at the physician's office, homeor other location (e.g., vacation hotel room). A dashboard diagnosticcan be executed on the laptop 835 that, in general, shows informationabout the status of the PPC 800 and the patient's medical device (e.g.,implanted CRM device or other PIMD). The dashboard diagnostic, analogousto an automobile's dashboard that has a variety of gauges andindicators, provides useful diagnostic information about the “health” ofthe PPC's connection with a communication medium (e.g., cellularnetwork) and with the PIMD 802 or other medical device or sensor withwhich the PPC 800 communicates.

The dashboard or other APM server-based application may be implementedto provide support for near real-time functions, such as PIMD 802 and/orPPC 800 interrogation, EGM and/or other sensor data streaming,over-the-air reconfiguring, software updating (e.g., PIMD firmwareupdates) and programming (e.g., modifying device parameters orinitiating physician commanded functions). Application level packets maybe transmitted to request information, and data mining may be performedon the PIMD 802 or PPC 800 by the physician or authorized user. Forexample, a dashboard application may provide for remote initiation ofclinician commanded atrial shock therapy. By way of further example, adashboard application may allow an authorized user to command the PPC800 to effect a scan of the PPC's local environment for RF interference.Data acquired from this scan can be shown on an “interference” indicatorof the dashboard.

A procedure may be established by which certain information is acquiredor exchanged with a PPC 800 that connects with the APM server 850. Ingeneral, it is preferably that the PPC 800 communicate with the APMserver 850 via a cellular network connection, by which the PPC 800 willinteract with the cellular network and exchange information packets withthe APM server 850. The PPC 800 is preferably programmed to periodicallycheck-in with the cellular network and with the APM server 850. The PPC800 may check-in several or many times per day with the cellular networkand generally checks-in only once or twice per day (under normalconditions) with the APM server 850.

During a cellular network check-in by the PPC 800, the PPC 800 obtainsnetwork/connectivity information such as signal strength, signalband/protocol, or other cellular network information/statistics. Duringan APM server check-in by the PPC 800, the PPC 800 exchanges patientPIMD/sensor data and further shares a sub-set of thatnetwork/connectivity information about its connectivity with the APMserver 850, primarily if the PPC 800 has a good connection (e.g., signalstrength, quality of service). Selected types of PIMD and networkconnectivity information may be presented on the dashboard 842.

Various types of diagnostic information acquired by the PPC 800 arepreferably made available to the physician or authorized user via adashboard display 842, which may be presented in a region of the display840 of a laptop 835 as shown in FIG. 9B. In addition to dashboardinformation, various types of patient information received from the APMserver 850 may be displayed in a patient data portion 853 of the display840. As with the patient related data, the dashboard data is preferablypulled from the APM server 850 by way of a secured network connection tothe laptop or personal computer.

As can be seen in the dashboard 842 in FIG. 9B, a dashboard diagnosticoperating on a physician or other authorized user's laptop or personalcomputer 835 is configured to primarily show connectivity and statusinformation about the PPC 800 and PIMD 802. The layout of the dashboard842 shown in the embodiment of FIG. 9B includes a PIMD Connection window844, a Network Connection window 845, a Check-In indicator 846, aDocking Status indicator 847, a Battery Status indicator 848, and aPower Status indicator 849. It is understood that the type and number ofdata windows and indicators shown in FIG. 9B are for illustrativepurposes, and that other of different informational content and mannersof displaying same are contemplated.

The Network Connection window 845 provides various information regardingthe connection between the PPC 800 and the network 830. The NetworkConnection Window 845 indicates the present connection state between thePPC 800 and the network 830 (e.g., “live” or “offline). Such informationincludes whether or not the patient's PPC 800 is presently connected tothe network 830 and by what means (e.g., cellular, land-line, satellite,etc.). As shown, the dashboard 842 shows that the PPC 800 is presentlyconnected to the network 830 (i.e., Status: “Live”) and that the presentconnection is via a cellular connection (i.e., Link: “Cell”). It isnoted that additional details concerning the “Link” may be displayed,such as by clicking on the “Link” label/button. The strength of theconnection between the PPC 800 and the network 830 is shown, such as byuse of commonly used signal strength bars. Any faults that have occurredcan be viewed in a Fault window.

Other information shown in the Network Connection window 845 includesthe day/time of the last or previous contact between the PPC 800 and thenetwork 830/APM server 850, and the last day/time data was transferredbetween the PPC 800 and the APM server 850. If the physician wishes tosee details about the last transfer of information or last connection,additional information may be presented by clicking on the “Last Xfr”label/button or “Last Link” label/button. Still other informationincludes the location status of the PPC 800, such as whether the PPC 800is presently stationary (e.g., at the patient's office or home) ormobile. The Location indicator of the Network Connection window 845shows that the PPC 800 is presently at the patient's home.

A PIMD Connection window 844 of the dashboard 842 provides variousinformation regarding the connection between the PPC 800 and the PIMD802. The PIMD Connection window 845 indicates the present connectionstate between the PPC 800 and the PIMD 802 (e.g., “live” or “offline).As shown, the dashboard 842 shows that the PPC 800 is presently notcommunicating with the PIMD 802 (i.e., Status: “Offline”). The strengthof the connection between the PPC 800 and the PIMD network 830 (presentstrength if connected or of last connection) is shown, such as by use ofcommonly used signal strength bars.

Other information shown in the PIMD Connection window 844 includes theday/time of the last or previous contact between the PPC 800 and thePIMD 802, and the last day/time data was transferred between the PPC 800and the PIMD 802. If the physician wishes to see details about the lasttransfer of information or last connection, additional information maybe presented by clicking on the “Last Xfr” label/button or “Last Link”label/button in PIMD Connection window 844. Further information includesthe status of the PIMD battery and the fault and/or alert status of thePIMD 802. If the physician wishes to see details about the PIMD faultsor alerts, additional information may be presented by clicking on the“Faults” label/button.

The dashboard 842 may include other informational indicators, such as aCheck-In indicator 846. The Check-In indicator 846 provides informationbased on the PPC's most recent connectivity information upload. In theillustrative example shown in FIG. 9B, the Check-In indicator 846includes a multi-state indicator comprising three colored indicators;red (i.e., circled “R”), yellow (i.e., circled “Y”), and green (i.e.,circled “G”). When the physician clicks on a patient's detail page, suchas that shown presented in display 840, the physician can see the stateof the “red-yellow-green” indicator 846.

If the PPC 800 has not checked-in with the APM server 850 within sometime period, the Check-In indicator 846 will show “red.” If the PPC 800has checked-in with only a low/moderate indication of signal strength,the Check-In indicator 846 will show “yellow.” If the PPC 800 haschecked-in regularly (e.g., 2 or more times within a specified timeperiod) with good signal strength, the Check-In indicator 846 will show“green.”

Based on a “green” indication, the APM server web page can allow aphysician to initiate an “active connection” with the PPC 800. It isdesirable (or may be mandatory) that an active connection be establishedwhen both the PPC 800 and the PIMD 802 are not mobile, which may bedetermined based on the stability of signal strengths or other means.When a non-mobile active connection of sufficient strength isestablished, the APM server's user interface can allow the physician toinitiate an active session. An active connection can allow for a varietyof operations, such as real-time streaming of EGMs, physician-initiatedinterrogation, sending a message to the patient, and remote programming,among others. The APM server's web site can also allow some actions tobe performed, even if there can not be an active connection. Forexample, various types of messages can be transmitted to the PPC 800 orqueued to transmit to the PPC 800 when a cellular connection isestablished.

The PPC 800 may incorporate a display that includes some or all of theindicators provided in the dashboard 842, although various embodimentsof the PPC 800 may have a limited user interface, such as in the case ofa reduced feature-set PPC 800. For example, the display of the PPC 800may display an indication to the patient about signal strength (e.g.,signal strength bars). It might only display the exception (e.g., yellowor red LED in cases where there is either unstable or no connection). Anindicator of the PPC 800 may offer some indication to the patient that aphysician/clinical user of the APM server's web site has established an“active connection” with the PPC 800. An alert status indicator (e.g.,red LED) may be programmable by the physician/clinical user andactivated via the APM server's web site to alert the patient of aproblem, thus prompting the patient to contact the physician or APMservice representative.

In the Network Connection window 845, an indication of the presentlocation of the PPC 800, in the case of a live connection, or the mostrecent location, in the case of an offline status indication, isprovided to the physician or authorized user. This location informationmay be used for a variety of purposes, including estimating thestability of the connection if an important data transfer operation isto be conducted (e.g., a PIMD or communicator firmware update), andchanging the connection attributes, data access rights, and/orfunctionality of the PPC 800 depending on location (e.g., greaterrights/access granted if at home versus overseas), among others. It isnoted that, if the connection status indicator in the Network Connectionwindow 845 indicates that the PPC 800 is “Offline,” the most recentdashboard information is presented. The manner in which the location ofthe PPC 800, including the present geographical location of the PPC 800if not at the patient's home, may be determined is discussedhereinbelow.

The dashboard 842 will indicate if the PPC 800 is mobile and if it is atits “home” location. As previously mentioned, this can be important fordetermining if the patient is likely at their place of residence (orother known location such as the patient's office) and if the quality ofthe cellular connection is likely to be stable. The PPC 800 has a setupprocedure, performed once during setup, that will ask the user “are youcurrently in your home location?” and allow the user to respond withYes/No. This location can be determined by cell system features. Thislocation can also be identified by the set of cell towers and relativesignal strength from each. The PPC 800 stores this “home profile” ininternal memory so that it can be tracked later. The Network Connectionwindow 845 of the dashboard 842 will indicate “Not at Home” when the setof cell towers/signal strength does not match the home profile.

A number of indicators tracked by the PPC 800 can be used to determineif the PPC 800 is “mobile” or stationary. For example, a PPC 800 that isswitching to multiple different cell towers within a predetermined timeperiod (e.g., the last 10 minutes) is considered mobile. A PPC 800 thathas large variations in signal strength with the same cell tower withina predetermined time period (e.g., the last 10 minutes) is consideredmobile. Various known cellular-based locating techniques (e.g.,triangulation) may be used to determine the present location of the PPC800. In some embodiments, a GPS receiver may be provided on the PPC 800or be communicatively coupled (wirelessly or wired) to the PPC 800. Forexample, a Bluetooth enabled GPS receiver implemented in a portablehousing or a GPS receiver integrated into automobile electronics may bepaired with the PPC 800 and provide high precision location informationto the PPC 800. This location information may be transmitted to the APMserver 850 and made available to the physician. An indication of thepresent location of the PPC 800 is preferably presented on the dashboard842.

The dashboard 842 is shown to include a docking status indicator 847, abattery indicator 848, and a power status indicator 849. The dockingstatus indicator 847 indicates whether or not the PPC 800 is presentlydocked with its corresponding base station or hub (e.g., “Y”=Yes ifdocked to its home hub or “N”=No if not docked to its home hub). A PPC800 will generally have a corresponding “home” hub that resides at thepatient's home, but may also have additional hubs, such as a hub thatresides at the patient's office. A portable or travel hub may also beused by the patient when traveling, which may incorporate additionalfeatures and functionality, such as a power source converter forconnecting with international power sources and a GPS receiver thatprovides the present location of the travel hub (and, therefore,provides a good estimate of the patient's location).

A PPC 800 is considered at its “home location” and not mobile when it isphysically connected to its home hub (or other known “stationary” hub).The power status indicator 849 of the dashboard 842 will indicate if thePPC 800 is currently powered by the hub's battery source or an AC poweradapter. The power status indicator 849 allows the physician to know inadvance if there is an external source of power for the PPC 800, so thatpower will not run out during a live communication session. The batteryindicator 848 of the dashboard 842 indicates the relative battery energylevel of the PPC 800. The battery indicator 848 allows the physician toknow if there is enough internal battery power, so that power will notrun out during a live communication session. The battery indicator 848may also include an indicator to show whether the internal battery powerof the PPC 800 is sufficient to provide 24 hours of PPC operation. Thisinformation may also be provided on the patient's home hub display sothat the patient/physician can be assured that a full day's charge isavailable.

The information provided on the dashboard 842 allows the physician toassess how the patient is using the PPC 800, such as whether the PPC 800is in communication range, being properly charged, turned on, etc. Overtime, the set of status data from the PPC 800 accumulates in the APMserver 850. This allows for a report or user interface to show thepatient, clinician, or medical device sales representative how effectivethe patient's use of the PPC 800 has been. Various metrics may becomputed, trended, and displayed, such as the percentage of time the PPC800 contacts the PIMD 802. This provides an indication of how many timesPIMD contact was attempted and the number or percentage of successfulcontacts.

Other useful metrics include an indication of the PPC's average batterypower (e.g., the PPC's charge history), whether the patient is keepingthe PPC 800 properly charged, how many times the battery has beencompletely exhausted, and how long the PPC 800 was completely off orinaccessible. The degree of mobility may be a useful metric thatindicates whether, and to what extend, the PPC 800 is moving or not.This provides an indication of whether patient is actually taking thePPC 800 with them during their normal activities. This can provide anindication of patient health and quality of life. For example, amobility metric can show if the patient is active. Metrics can begenerated that can be used to assess patient compliance and to implementcompliance training Various reports, statistics, and user interfaces canbe used to identify to the patient if they are not keeping the batterycharged or not carrying the PPC 800 with them, and encourage the patientto take corrective actions. Patient compliance information can also begenerated and presented that reinforces and encourages proper use of thePPC 800 by the patient.

It is contemplated that other dashboards can be implemented that provideuseful data for particularized users. For example, a dashboard may beimplemented that is oriented towards the clinician/physician. A separatedashboard may be implemented that is oriented towards more networkdiagnostic. Other dashboards may be implemented that are orientedtowards customer service centers for purposes of enhancingtroubleshooting efforts by technicians and clinicians.

Moreover, diagnostics other than those discussed above can be shown on adashboard 842. Such diagnostics include the following: frame error rateof the cellular network connection, frame error rate of the implanteddevice connection; state of the PPC/PIMD connection (e.g.,not-connected, attempting implant connection/wake-up, connected,failed/not-connected); current number of attempts to contact/wakeup thePIMD; last time the PPC had a user interaction (e.g., button pushed,placed on or removed from the docking station); transfer rate metrics(e.g., minimum bps, maximum bps, average bps) for the most recent datatransfer; and timestamped connectivity link change history (e.g.,GSM->WifF->GSM) since the PPC connected to the network. Otherdiagnostics and metrics are contemplated. Dashboard information may beupdated at a relatively slow rate, such as once per hour (or faster orslower as desired) Dashboard information may also be updated uponcommand. Dashboard information may be updated in response to aconnection being established between a PPC and the APM server 850.

Updating the firmware of the PPC 800 may be implemented using thedashboard diagnostic or other facility of the APM server 850. The PPC800 may be viewed as having different sets of firmware. A first set ofPPC firmware may be termed medical firmware, a second set of PPCfirmware may be termed user interface firmware, and a third set of PPCfirmware may be termed cellular radio firmware. These sets of firmwareoperate substantially independently yet cooperatively to seamlesslyeffect communications between a governmentally regulated “medicaldevice” (e.g., an implanted CRM device, which is a classified by the FDAas a Class III medical device) and a public communicationsinfrastructure (e.g., cellular network and the Internet). The proceduresand requirements for updating different sets of PPC firmware are quitedifferent.

The cellular radio firmware controls the interactions and communicationsto and from the PPC 800 and the cellular network. This firmware must beindependently versioned, tested, and controlled in conjunction with thenetwork providers. The cellular radio firmware is typically upgradedwithout the need for patient interaction, and can be actioned forupgrade by the cellular network provider or through the APM server 850.

The user interface firmware controls the visual and/or audio content ofthe PPC 800. The user interface firmware also contains the audiorecordings for any sounds generated by the PPC 800. This firmware isupdated preferably over-the-air, without involvement from the user. Itis controlled by the APM server 850.

The medical firmware controls the activities schedule of the PPC 800,communications between the PPC 800 and the PIMD 802 and other sensors,and data transfers to and from the APM server 850. The medical firmware,for example, ensures that all communications between the PPC 800 and thePIMD 802 conforms to predetermined medical device guidelines, which mayinclude regulatory guidelines that conform to security, encryption, andprivacy (e.g., HIPAA) requirements promulgated by a regulatory body,such as the U.S. Food and Drug Administration. The medical firmware alsoensures that all communications between the PPC 800 and the network 830and APM server 850 conform to such regulatory guidelines orrequirements. This firmware is updated preferably over-the-air, withoutinvolvement from the user.

Over-the-air programming (OTA) is also referred to as over-the-airservice provisioning (OTASP), over-the-air provisioning (OTAP) orover-the-air parameter administration (OTAPA), or firmware over-the-air(FOTA), each of which defines methods of distributing newsoftware/firmware updates to cellular phones or provisioning handsetswith the necessary settings with which to access services such as WAP orMMS. OTA via SMS, for example, can be implemented to optimize theconfiguration data updates in SIM cards and handsets, and enable thedistribution of new software/firmware updates to mobile phones orprovisioning handsets. OTA messaging provides for remote control ofmobile phones for service and subscription activation, personalizationand programming of a new service for network operators, for example.

In general, the APM server 850 is able to communicate to the cellularnetwork provider and/or queue a message that is general to all PPCs 800.The message is preferably pushed from the APM server 850/network 830 tothe PPCs 800 over the least expensive medium and during off-peak hours.An “upgrade available” broadcast message preferably causes the PPCs 800to initiate communications to the APM server 850 during an off-peakhour, and possibly at a randomized interval to avoid server/networkoverload, to commence with the upgrade download. The PPCs 800 may usethe hub communication medium to contact the server and download theupgrade.

The PPC 800 preferably includes software and hardware that support OTAupgrading. New software or firmware may be transferred from the cellularnetwork provider (or the APM server 850) to the PPC 800, installed, andput into use. It may be necessary to turn the PPC 800 off and back onfor the new programming to take effect, which can be programmed to occurautomatically at a time when PPC services are not required (e.g.,patient is sleeping with no anomalous physiologic conditions detected).

An OTA software or firmware upgrade session can be initiatedautomatically at an appropriate time or in response to a patient'sinput. For example, the cellular network provider or APM server 850 cansend an SMS message to the PPC 800 requesting the patient to enable theOTA software/firmware upgrade, such as by actuating an update button onthe PPC 800. In response, the PPC 800 dials a service number to receivea software/firmware update. It is understood that other modes ofperforming software/firmware upgrades for the PPC 800 may be used, suchas by establishing a wired connection with a server of the cellularnetwork provider or the APM server 850. It is further understood thatall or selected groups of PPCs 800 can be upgraded concurrently, such asby the cellular network provider or the APM server 850 broadcasting anSMS message indicating that an upgrade is needed or by performing theupgrade automatically at an appropriate time.

According to some embodiments, firmware upgrades are performed by thecellular network provider pushing the firmware updates to one or morePPCs 800. The updates are tracked on a per-radio basis, such as by useof SIM identification. Firmware updates for each of a PPC's cellularradio firmware, user interface firmware, and medical firmware is trackedand made accessible on the dashboard 842. Notification of a firmwareupdate is generated by the cellular network provider and received by theAPM server 850. The update receipt is preferably pulled in by the APMserver 850. A check is made to determine if all designated PPCs 800 weresuccessfully upgraded. For PPCs 800 that either did not receive theupdate (e.g., PPC 800 out of range, poor connection, or turned off) orfailed to successfully implement the update (e.g., update wasinterrupted), the updating procedure is repeated. As was mentionedpreviously, the updates can be coordinated and delivered by the cellularnetwork provider, the APM server 850 or both.

Generally, the cellular network operator is able to determine which PPCs800 have what versions of firmware. Reports are typically available todetermine which PPCs 800 have older firmware revisions that still needto be updated. These PPCs 800 can be re-targeted for a firmware update.Patients who have these PPCs 800 can be contacted by a customer supportrepresentative.

When the PPC 800 is connected to the network 830 and signal strengthsand time of day/patient condition are appropriate, a firmware upgradepackage is delivered to the PPC 800. The signal strength and batteryneed to be consistent for a complete transmission. The appropriate timeof day can be determined according to network availability and datatransfer fees. Night-time/low utilization periods should be preferred.As an alternative implementation for firmware updates, all firmwareupdates may be sent to the cellular network provider. The cellularnetwork provider preferably uses over-the-air transmission forinstalling the updates, and the cellular network identifies the PPCs 800that need the upgrade.

As was previously discussed, the status of each set of PPC firmware ispreferably made available on the dashboard 842. Firmware status andupdates are preferably tracked on the basis of individual PPC radio,typically by way of SIM data. It may be desirable to provide two or moredashboards, each tailored for a particular user. For example, aphysician dashboard may include higher level/summarized informationrelating to the patient or a group/population of patients, the connectedstate of the PPC(s) 800, availability of active-connection(s), andpatient compliance. In general, the physician does not need all of thedetailed connectivity information that is available. A customer servicedashboard may include full details, including actual signal strengths,diagnostic information, etc. The customer service dashboard may alsoprovide information about groups or populations of patients and/orusers. For example, data about what fraction of patients/users arecurrently connected, recently connected, out of range, etc., may beaccessed via the customer service dashboard, which can provide customerservice personnel with valuable information about problem areas that canbe further investigated in greater detail.

A PIMD programmer dashboard may be implemented that provides informationof particular use to physicians that are accustomed to using atraditional implantable medical device programmer. In general, most ofthe information that is of interest about a PPC 800 also applies to aPIMD programmer that is connected and on a cellular network. Forexample, information and trending data on the connectivity status ofPIMD programmer, such as signal strengths and percentage of timeconnected, can be obtained and presented on the programmer dashboard.Information regarding the last check-in by the PIMD programmer,including data, time, and interrogation information, is preferablytransferred to the APM server 850 from the PIMD programmer and presentedon the PIMD programmer dashboard. The location where a particularprogrammer is and/or where a given interrogation occurred can bedetermined and tracked. For example, a programmer is generally anexpensive piece of equipment, and it is important to have programmerinformation for equipment tracking, determining equipment location andavailability, and determining equipment servicing needs.

During use, the PIMD programmer can store data in its internal memoryfor later upload to the APM server 50. The programmer can indicate thatit has data ready for upload/streaming and, when connected to thenetwork 830, the programmer can upload the data to the APM server 850.Data associated with implanting a PIMD, for example, can be stored inthe programmer's memory for real-time or later transfer to the APMserver 850. By way of example, during a PIMD or other medical deviceimplant procedure, a number of records are written, logged, typed, andprinted. All or selected records associated with the implant may becommunicated from the programmer to the APM server 850. This implantdata may be accessed and evaluated by physicians, clinics and hospitalpersonnel and data systems, and medical device manufacturerrepresentatives, for example.

The PIMD programmer can be used to facilitate an active session with theAPM server 850 and the PIMD 802, in a manner like the PPC 800. Featuressuch as real-time EGM streaming, for example, are made available. Thesoftware and firmware installed on each programmer must generally betracked by the medical device manufacture to meet tracking requirements.The current version of programmer software, firmware, and otherconfiguration and diagnostic information about the programmer ispreferably uploaded to the APM server 850 and made available on the PIMDprogrammer dashboard.

PPC/Programmer

According to some embodiments, a PPC 800 may be configured for use as acomponent of the in-clinic/operating room PIMD programmer. In thisregard, the PPC 800 is configured as a “dual use communicator,” in thatthe PPC 800 is used as a programmer in clinic and as a communicator outof clinic. The PPC 800 can be paired/assigned to the patient and thePIMD at the time of implant. The PPC 800 is utilized as a “smart wand”during the implant operation and initial follow-ups. The patient couldbe enrolled in the APM system at this same time. Advantageously, the PPC800 stays with the patient as the patient leaves the operating room.

The PPC 800 can be used as a “smart wand” that communicates with thePIMD via telemetry and to the programmer user station via another RFlink (e.g., Wi-Fi or Bluetooth) or other information system/laptopcomputer. When used during PIMD implant, the data can be transferredbetween a laptop (e.g., used by the PIMD sales representative), PPC 800,PIMD, and programmer. In one configuration, direct communication betweenthe laptop and the PPC 800 is effected using a Bluetooth link.

At the time of implant, the PIMD sales representative typically recordsa large amount of patient information (e.g., name, age, physician'sname, notes) and PIMD information (lead models, serial numbers, IPGmodel/serial number, etc.). The sales representative types thisinformation into the information system's laptop. The salesrepresentative must then re-enter the same information into theprogrammer's user interface. Rather than re-input this information, thesales representative may instead press a “program to patientcommunicator” button on the laptop. The data is then transferred to thePPC 800. Rather than using the programmer for PIMD data transfer, thePPC 800 then programs this data to the PIMD, thus acting as a “smartwand” and eliminating duplicative entry of the patient information.

One benefit obtained when using the PPC 800 as a “smart wand” is thatthe patient/PIMD is monitored immediately after the PIMD is implanted.Alerts and monitoring are active immediately and available during thepatient's stay in the hospital and immediately after discharge. Thepatient is able to be trained and familiarize themselves and familymembers with the PPC 800.

Pairing the PIMD with the PPC

One aspect of the life critical network involves the process of pairingthe patient implantable medical device with a PPC. Pairingcommunicatively links a PPC with a particular PIMD to form a uniquePIMD-PPC pair. Pairing is typically performed during an initializationprocess and occurs before patient specific data can be transferredbetween the PIMD and the PPC. Re-pairing may need to be performed in theevent that one or both of the paired devices is replaced or losespairing information.

Pairing involves exchanging or otherwise providing pairing informationto one or both devices that is used to communicatively link devices in aunique PIMD-PPC pair. Pairing information may include deviceidentification information, patient identification information,cryptographic keys, and/or other information that can be used toestablish and maintain a secure and reliable communication link betweenthe PIMD and its paired PPC. Pairing information is typically maintainedwithin the PPC and/or the PIMD and may be provided, exchanged and/ordeveloped before or during pairing between the PIMD and the PPC.

FIG. 4A illustrates a plurality of PIMD-PPC pairs 401 and an APM server403 in a life critical network 400. The PIMD 402 and the PPC 404 of eachPIMD-PPC pair 401 are paired by a bi-directional communication link 405between the PIMD 402 and PPC 404. For example, the bi-directionalcommunication link 405 may involve RF telemetry utilizing MICS, ISM,SRD, or other appropriate radio bands. Following a pairing process thatuniquely links a PIMD 402 and PPC 404 to form a PIMD-PPC pair 401,information may be transferred between the PIMD 402 and its linked PPC404 via the RF link 405 and between the PPC 404 to the APM server 403via a cellular network 406.

The PIMD and/or PPC may include one or more components and/or processesto facilitate pairing and/or to allow interaction between the PIMD-PPCpair and the patient. For example, as described in more detail herein,the PIMD 402 and/or PPC 404 include software, firmware and/or hardware407, 417 that stores pairing information and/or stores and executes theprogram commands used in the pairing process. The PIMD 402 and/or PPC404 may also include sensors 408, 418 used to verify proper pairing,determine proximity of the PIMD 402 to the PPC 404, and/or to providepatient incentives that encourage the patient to carry the PPC 404 sothat the PIMD 402 and PPC 404 can maintain communication. The PIMD 402and/or PPC 404 may also include components and/or processes 409, 419used to generate an alert or provide for other types of communicationwith the patient.

In one scenario, and with reference to FIG. 4B, pairing information thatis used to communicatively link a particular PPC with a particular PIMDmay be permanently stored in the PPC and/or PIMD. For example, asillustrated in FIG. 4A, after information about a patient and/or thePIMD of a patient requesting a PPC is determined 411, pairinginformation may be stored 412 in the memory of the PPC duringmanufacturing. For example, when the PPC is destined to be paired with aparticular PIMD, the PIMD ID and/or the patient ID is hardwired into thePPC or flashed to a flash programmable ROM of the PPC. The APM server ofthe life critical network is programmed 413 to recognize the PIMD-PPCpair.

The PPC is then transferred to the patient that is implanted with theparticular PIMD. When the patient's PIMD is in proximity with the PPC, apairing initialization process is performed. The pairing initializationmay be started, for example, by command from the APM server or bypressing a button on the PPC that puts PPC into pairing initializationmode. The PPC interrogates the PIMD to start 414 a pairinginitialization process that pairs the PIMD and the PPC. During thepairing initialization, the PPC may query the PIMD requesting that thePIMD send pairing information (e.g., the PIMD ID) to the PPC. The PPCconfirms that the pairing information acquired from the PIMD matches thepairing information hardwired or programmed into the PPC. If so, thePIMD and the PPC are paired by the initialization process. Additionalinformation to facilitate secure communication between the PIMD and thePPC may be transferred from the PPC to the PIMD. If the pairinginitialization is successful, a secure communication link connects thePIMD-PPC pair and establishes 415 the PIMD and PPC as paired devices inthe life critical network.

One authentication mechanism that may be used to pair the PIMD and thePPC is the “challenge/response” approach. A PIMD or PPC wanting toauthenticate another device creates a random challenge message and sendsit to that device. The device receiving the challenge message adds atimestamp and signs it with a private key (from a public/private keypair). The signed response is returned to the challenger, who can checkit with the public key. If it passes, and the time stamp is “recent,”then the challenger knows that the other device really has the privatekey. As long as keys are secured, the receiver has to be the authenticowner of that public/private key pair. Authentication can also beperformed with symmetric keys, if a means is provided to ensure that thesame key is in both systems in a secure manner, but a public keyinfrastructure (PKI) may be preferred for some applications.

A PIMD can be manufactured to include the public certificate for theserver. The server has a private key well secured, such as secured inhardware encryption modules. The PPC has a private key, and the serverhas the public keys for all manufactured PPCs. However, the PIMD may nothave enough memory to store the public keys for all PPCs, or the PIMDmay be implanted before its associated PPC is manufactured.

In a single transaction, the server can authenticate the PPC, and thenprovide those authentication credentials to the PIMD—there is a “chainof trust”—the PIMD can trust the server, so once the serverauthenticates the PPC, it can “vouch” for the PPC to the PIMD. Once thePIMD can trust the PPC, it can pair with it—they can exchange securekeys for future sessions.

Pairing information may be programmed into the PPC and/or PIMD during aclinic visit. Pairing information that is programmed in the PPC and/orPIMD at a clinic visit provides a more flexible option than programmingor otherwise embedding the pairing information into the PPC and/or PIMDduring manufacture of the devices. In one scenario, pairing informationmay be flashed to ROM in the PPC or otherwise stored in memory of thePPC while the patient is at the clinic to ensure that the PPC and PIMDdevices are correctly paired. Flash programming the PPC with pairinginformation may be performed at a physician's office, hospital, clinic,or other medical facility having equipment for programming the PPC. Insome implementations, the PIMD may also be programmed at the clinic withpairing information that corresponds to the pairing informationprogrammed into the PPC. Programming the PPC and/or the PIMD andperforming pairing initialization during a patient visit to the clinicallows the clinic to have a number of unpaired PPC's on hand which canthen be provided to patients on an as-needed basis. The use of unpairedPPCs that can be later programmed to be paired with PIMDs significantlyreduces the administrative effort required to ensure that a patientreceives the PPC which contains pairing information that allows pairingwith the particular PIMD of the patient.

In one exemplary process, illustrated by the flow diagram of FIG. 4C,the medical facility has 421 on hand a supply of unpaired PPC's.Immediately following implantation or during a follow-up visit, thepatient having a PIMD is provided with 422 an unpaired PPC. The ID ofthe PPC, the ID of the patient's PIMD, the ID of the patient, and/orother pairing information unique to the patient, the PIMD, and/or PPC isascertained 423, such as by accessing the APM server where suchinformation is stored. The ROM of the PPC is flashed 424 with thepairing information or the information is otherwise stored in the PPCmemory.

When the pairing initialization mode of the PPC is activated and the PPCis in communication proximity with the PIMD, the PPC initiates 425 thepairing process. The pairing initialization process may involveproviding the PIMD with the ID of the PPC, exchanging encryption keys,and/or providing or exchanging other information to form the PIMD-PPCpair.

In some implementations, the pairing initialization process may requirethat the PIMD also be placed in pairing mode, for example, through theuse of a command issued by a device programmer which is in communicationwith the PIMD. During pairing mode, the PIMD is placed in a statewherein the PIMD is ready to accept communications from a PPC and/or toparticipate in an exchange of pairing information with the PPC to form aPIMD-PPC pair.

After the pairing initialization process is performed, the PIMD and thePPC are 426 paired devices on the LCN. The PPC may communicate 427 withthe APM server to report that the pairing was successful. In the eventthat pairing could not be completed, the PPC would report anunsuccessful pairing attempt.

In a similar implementation, illustrated in FIG. 4D, unpaired PPC's canbe paired with patient's PIMD by storing pairing information in the PIMDat the hospital or clinic, for example. The ID of the PPC, which may bethe international mobile subscriber identity (IMSI) of the PPC'ssubscriber interface module (SIM), and/or other pairing information isdetermined 433. The pairing information can be programmed 434 into thePIMD via a device programmer. After programming the PIMD with thepairing information, the pairing initialization process involves arequest 435 for pairing by the PPC directed to the PIMD. The PIMDrecognizes 436 the ID of the PPC, allowing pairing to proceed. Afterpairing, the PPC notifies 437 the APM server that the pairing iscomplete.

The use of the SIM ID of the PPC for pairing allows pairing to bemaintained even if the patient receives a new PPC. The SIM card from theold PPC can be moved to the new PPC and, through the SIM ID, the new PPCremains paired to the patient's PIMD.

In some implementations, pairing information may be acquired by the PPCfrom the APM server before pairing begins. This pairing technique, whichis illustrated in the flow diagram of FIG. 4E, allows for clinic- orhome-based pairing. An unpaired PPC is delivered 441 to the patient'shome or to the clinic. Pairing between the PIMD and the PPC may beinitiated 442 by the patient or medical professional. In one scenario,pairing may be initiated by activating the PPC and/or by pressing abutton on the PPC which causes the PPC to establish 442 communicationwith the APM server for the purpose of downloading pairing information.Alternatively, the patient may call the APM medical service center whenready to begin pairing. The server then is made to establishcommunication with the PPC and push the pairing information to the PPC.After receiving the pairing information, when the PPC is incommunication proximity with the PIMD, the PPC initiates communication443 with the PIMD and transmits the pairing information. If the pairinginitialization process is successful, the PIMD and the PPC are paireddevices 444 on the LCN. The PPC reports back 445 to the server regardingthe success or failure of the pairing initialization.

The pairing scenarios illustrated in FIGS. 4C and 4D include involvementof the APM server, programmer, and/or other device communicating withthe PPC and/or PIMD to assist in providing pairing information to thePPC or PIMD. It is desirable in some situations for the PPC and PIMD tobe capable of autonomous pairing without involvement from an externaldevice. Autonomous pairing is particularly useful because the PPC can beshipped directly to the patient. Autonomous pairing also allows forre-pairing between the PPC and the PIMD. Re-pairing may be performed ifeither of the devices lose pairing information after the initial pairingwhich makes a subsequent pairing operation necessary to reinstatecommunication between the PPC and the PIMD.

FIG. 4F is a flow diagram illustrating an autonomous pairing processbetween a PIMD and PPC. In this implementation, the patient receives 451the PPC. The patient activates the PPC and the PPC enters 452 pairingmode. For example, the patient may push a button that causes the PPC toenter pairing mode. In one implementation, the PPC initiatescommunication with the PIMD and the PPC and PIMD exchange 453 pairinginformation. In some implementations, the PPC is equipped with a radiofrequency identification (RFID) interrogator and the PPC reads an RFIDtag in the PIMD to identify the PIMD and/or leads or other implantedhardware/sensors.

After pairing, the PIMD-PPC are 454 paired devices in the LCN. The PPCinforms 455 the server that the PIMD-PPC pairing has occurred andinforms the server of the specifics of the pairing, e.g., the IDs of thepaired devices.

In autonomous pairing situations where there may be more than one PIMDin range of the unpaired PPC attempting to initiate pairing, it isadvantageous to ensure that the unpaired PPC is pairing with the properPIMD. Improper pairing or improper re-pairing may be avoided, forexample, by acquiring physiological data from the patient via sensors onthe PPC and comparing the physiological data acquired by the PPC tosensed physiological data acquired by the PIMD that is implanted in thepatient.

In one exemplary embodiment, shown in FIG. 5A, the PPC 460 is equippedwith one or more sensors 461 configured to sense a physiologicalparameter of the patient. For example, the sensors 461 may includemetallic sensors for skin contact with the patient through which thepatient's heartbeat is acquired. The sensors are coupled to electronics(e.g., amplifies, filters, signal processors, and/or other circuitry)that provides a heartbeat signal detector 462 within the PPC.

As illustrated the flow diagram of FIG. 5B, physiological data for aparticular parameter (e.g., patient's heartbeat signal) is acquired 463by sensors and/or circuitry on or in the housing of the PPC.Physiological data for the same parameter is also acquired 464 by thePIMD. The physiological data acquired by the PPC is compared 465 to thatacquired by the PIMD. For example, the signal morphology, heart rate, orother characteristics extracted from the heartbeat signals acquired bythe PPC and the PIMD, respectively, may be compared to check for amatch. If the physiological data acquired by the PPC is consistent 466with the physiological data acquired by the PIMD, then the pairing isproper and continues 467. If the physiological data acquired by the PPCis inconsistent 466 with the physiological data acquired by the PIMD,the PPC is most likely attempting to pair with a PIMD other than thePIMD implanted in the patient. In this situation, the pairing isimproper and is terminated 468.

The PPC may be equipped with sensors for sensing any type ofphysiological data that can be verified by the PIMD to confirm properpairing. For example, the PPC may include the metallic sensors for skincontact as described above and/or may include a microphone for detectingrespiration sounds and/or heart sounds which may be detected if the PPCis held near the body. The PPC may alternatively or additionally includea posture sensor, motion sensor, pulse oximeter, and/or other suitablesensors that may be used to verify proper pairing through comparison ofinformation acquired by the PPC sensors with information acquired usingcorresponding sensors of the PIMD. In one configuration, to verifyproper pairing, the PIMD may pace at a specified rate, such as 65 ppm,during a pairing verification process. The PPC detects the heart beat,for example, by skin contact via metallic contacts on the PPC, and/or byinductively sensing the electric field generated by the pacing pulseswithout metal-skin contact. If the heart beat or pacing pulses occur atthe specified rate, proper pairing is verified.

In one implementation, the PIMD is equipped with a light detector andthe PPC includes a light source. By holding the PPC outside thepatient's body but oriented with respect to the PIMD so that lightemitted by the PPC can be detected through the patient's skin by thePIMD, the PPC can send an optical signal to the PIMD to verify properpairing.

The pairing process outlined by FIG. 5B is particularly useful inautonomous pairing or re-pairing the PPC and the PIMD. As previouslydiscussed, re-pairing may become necessary if the pairing information ofeither device is lost, for example, in the event that the either the PPCor PIMD have memory loss which may result from a software reset orbattery depletion.

A variety of pairing scenarios are made possible by the portability andmobile connectivity features of a PPC implemented in accordance with thepresent invention. Pairing between a PPC and a PIMD may be performed atdifferent locales, each of which may implicate different levels ofpairing functionality. For example, pairing that occurs at a thehospital or a physician's clinic may implicate a full range of pairingfeatures, while pairing that occurs at the patient's home may implicatea reduced range of pairing features.

Pairing between a PPC and a PIMD may be performed wirelessly between anAPM server and a PPC. The APM server can initiate the pairing operation,and authentication can be performed during initiation of the pairing,which may involve use of a pseudo certificate or other form of robustauthentication that is preferably based on more that the serial numberof the PIMD. A wireless pairing approach enables relatively fast paringof a PPC to its associated PIMD. A wireless pairing process provides theopportunity to have ongoing data transfer during the pairing operation.

A number of different wireless pairing scenarios are contemplated.According to one scenario, a “generic” PPC is delivered to the patient'shome. This “generic” PPC can represent an off-the-shelf PPC that has notbeen configured or programmed for operation with a particular PIMD.Instead, configuring the PPC for use with a particular patient's PIMDoccurs at the end destination (e.g., at the patient's home or aneighborhood clinic/physician's office). This scenario significantlyreduces the complexity and cost of pre-configuring each PPC for use witha particular PIMD at the medical device manufacturer facility andmeticulously tracking each pre-paired PPC through the delivery chain toensure the correct PPC is delivered to the correct patient.

A pairing scenario that employs “generic” rather than pre-set orpre-configured PPCs typically requires a greater level of authenticationto ensure an accurate and safe pairing of the “generic” PPC with a givenpatient's PIMD. A more robust authentication process may employ use ofreal-time data exchange (e.g., using private/public certificates)between the PPC and PIMD. PIMD data and SIM card data may be used aspart of the initial pairing and subsequently used for authenticationwhen the PPC connects with an APM server over the LCN. Cellular keys,encryption, and other security technology provided by the cellularnetwork provider may also be used to provide for enhanced security.

The International Mobile Equipment Identity or IMEI may also be used toenhance authentication robustness. The IMEI is a number unique to everyGSM and UMTS mobile device. It is usually found printed on the deviceitself, typically underneath the battery. The IMEI number is used by thenetwork to identify valid devices and therefore can be used to stop astolen or lost device from accessing the network. The IMEI is only usedto identify the device, and has no permanent or semi-permanent relationto the subscriber. Each PPC may have an IMEI that can be used to helpidentify the patient who receives a particular PPC, and may be ofparticular use during the first pairing operation (or initial pairingfor a particular patient in the case of a re-allocated PPC).

An advantage to using a SIM card in the PPC is that the SIM card canstore an authentication key itself (e.g., unique information about PIMDstored in the SIM card after the first pairing). After the firstpairing, the SIM card can be moved (swapped) from one PPC to another PPC(e.g., a new PPC or a “borrowed” PPC) by the patient, clinician ortechnician. This approach advantageously allows PPCs to retain their“generic” configurable character. According to one approach, the APMserver may be used to manage inventories of SIM cards that are in use.Proper management of SIM cards allows for reuse or re-pooling of SIMcards and numbers. For example, a patient may want to keep a particularPPC that needs to be re-initialized with a new SIM card or SIM number.Re-initialization may be performed by the APM server.

Another pairing scenario involves two or more patients in the same homethat have PPCs or receive PPCs around the same time. During initialpairing within a multiple-PPC environment, it may be beneficial to usepatient-unique information to ensure that a given PPC is paired with thecorrect patient. In one approach, a physiologic signature unique to thepatient may be sensed by a sensor on the PPC's housing, such as a heartrate sensor. An indicator on the PPC may indicate whether or not thecorrect PPC is paired with the correct patient. In another approach, itmay be advantageous to permit two patient PIMDs to use either of thepatient's PPCs. In this situation, a PPC may be paired with more thanone PIMD.

In-clinic pairing may allow for enhanced features and functionality.Pairing a PPC with a patient's PIMD in a clinic allows for efficientinput of needed PIMD, PPC, and patient data into the APM server. Whencreating or updating patient data stored in the APM server, identity andother information about a new or re-used PPC (e.g. model number, serialnumber, SIM card information IMEI number, etc.) can be entered into theAPM system interface. Since data entry occurs at the clinic and isrecognized as such by the APM system, security protocols need not be asstringent as in the case of non-clinic or public scenarios. If PIMD andPPC pairing involves a magnet mode, then the data can be synchronizedafter use of the magnet.

A unique web based PPC interface for use in the clinic or physician'soffice may be presented to the clinician to facilitate in-clinicprogramming and reprogramming of the PPC. The clinic or physician'soffice may be equipped with a “super” access point web facility that caneliminate the need for an in-office programmer(s). An interlock featuremay be used to enable a class of commands that allows programming of thePPC based on the in-office PPC communicating with the in-clinic weblaptop or computer. The PPC may pass an optical code or other securityidentifier to the in-clinic web laptop as a security lock. The clinicmay pass an inductive or RF device in proximity to the PPC in the clinicthat ensures that the PPC is, in fact, at the clinic. This may alsoprovide a basis for indicating patient consent to make the programmingchanges. The physician may enter a certificate as a surrogate to makeprogramming changes.

In one approach, signal strength between the PPC and the clinic's Wi-Fior wireless access device (which will be high within the clinic) may beused to confirm that the PPC is indeed at the clinic during theinitialization or updating procedure. The PIMD may be programmed togenerate an audible or ultrasonic tone that can be detected to indicatePIMD pairing with a new PPC. A microphone on the PPC may be used to pickup an audible tone or, in an alternative approach, pick up the patient'sheart rate, in which case there is no need for a PIMD generated tone.

In another scenario, it may be irrelevant which PPC is paired with whichPIMD. In this scenario, all PIMD data is identified by PIMD serialnumber and perhaps other information so that, no matter which PPC isused, the PIMD data that is received at the APM server is properlyassociated with the correct patient. This “soft pairing” approach cansignificantly reduce the complexities of “hard” PPC pairing approaches.It is noted that the PPC through which a PIMD communicates with the APMserver will still have to be properly authenticated and authorized forconnection with the APM server.

Hard PPC pairing has several advantages over soft pairing. Because hardpairing involves pairing of a specific PPC with a specific PIMD,repeated or duplicative transfers of the same data from the PIMD to thePPC and from the PPC to the APM server can be avoided. PIMD power can beconserved by eliminating redundant wake-up and connection operationsbetween the PIMD and a multiplicity of different PPCs which can occurwhen using soft pairing. Moreover, precious PIMD power can be conservedby eliminating duplicative signaling and data transfers between the PIMDand the PPCs. One approach to conserving PIMD power when a soft pairingapproach is used involves limiting the number of signaling and datatransfer event between the PIMD and the PPCs, with the exception of highpriority/criticality events.

Lost or Inadvertently Exchanged PPC

Over the course of time, the patient may lose or temporarily misplacethe PPC. In situations where PIMD-PPC patients live nearby or interactwith other patients having PIMD-PPCs, the PPCs, which may look verysimilar, can be inadvertently exchanged between the patients. If thepatient's PPC is misplaced, forgotten or inadvertently exchanged, thismay result in loss of periodic updates from the PPC, event drivenupdates and/or may preclude life critical PPC alerts to the APM serverif the patient experiences a significant cardiac or physiological event.

Various safeguards may be incorporated in the PPC to avoid or preventloss or inadvertent exchange of the PPC. For example the PPC, the PIMD,or both, may include processes or mechanisms that to detect if the PIMDand PPC are out of range and to alert the patient. The possible patientalert mechanisms may include a vibratory alert, a visual alert, and/oran audible alert.

The PPC may include a proximity detector that determines if the PPC issufficiently close to the PIMD to maintain communication between thedevices. If the PPC detects that the PIMD is out of communication range,the PPC and/or PIMD may send an alert to the patient. For example, thePPC may be equipped with a beeper that is activated if the PIMD is outof range of the PPC. In another example, if the PIMD has notcommunicated with the PPC for predetermined time interval, the PIMD mayvibrate to notify the patient. In yet another example, the PPC may senda message, such as an SMS message, to the patient's cell phone and/ormay notify the APM server if the PIMD and PPC have been out of rangeand/or have not communicated for a period of time. The manner and extentof alerting the patient that the PPC is out of range of the PIMDgenerally depends on the patient and his or her condition. For example,the PPC of a typically bradycardia patient may need to communicateinfrequently with the APM server. In this case, proximity alerts may bemore subtle and infrequent. For a patient having severe heart failure,this patient may need to communicate frequently with the APM server, inwhich case proximity alerts may be more conspicuous and frequent.

The PIMD may be equipped with a beeper and/or vibrator and the PPC maybe equipped with a light, beeper and/or vibrator, or other type ofalert. One or more of the alert mechanisms may be activated if the PIMDis out of range of the PPC or if the PIMD and PPC are not incommunication. The alert may be based on a time limit trigger, i.e., thealert is generated after the PPC and PIMD are out of communication rangefor more than a predetermined period of time. Any combination of stimuliperceptible by the patient that can be generated by the PPC and/or PIMDmay be used to notify the patient of the out or range or loss ofcommunication condition. Such perceptible stimuli may be coupled withmessaging to the patient's cell phone, pager, or to the APM server bythe PPC to indicate the out of range or loss of communication condition.

The PPC may include a global positioning system (GPS) functionality and,in the event the PPC is lost, the last known GPS address of the PPC maybe used to find the lost PPC. Alternatively, if the PPC is stillenergized, the general location of a lost PPC may be located via pingsfrom the base station.

The PPC and the PPC docking station or hub may cooperate to provide alocator feature. For example, to locate a lost PPC, the patient may pusha locator button on the docking station which causes the PPC to emit acombination of light, tones, or vibration to assist the patient inlocating a lost PPC.

Patient/System Interactions

As illustrated in FIG. 4A, the PPC is coupled through an RF telemetrylink to a PIMD and is coupled through a mobile communication network,such as a mobile cellular network, to the APM server. The mobilecellular connectivity of the PPC provides for a variety of interactionsbetween the patient and the APM system, between the patient and thePIMD-PPC pair, and/or between the patient or PIMD-PPC pair and otherservices accessible via the mobile cellular network.

Exemplary services that may be provided through use of the PIMD-PPCpair, involve medication management for the patient, medication schedulecompliance tracking, exercise schedule compliance tracking, and/orperiodic physiological test compliance tracking, compliance tracking ofprescribed external therapies (e.g., patient use of CPAP or oxygentherapies), prescription refills, and/or information relayed to thepatient's physician, patient advocate or APM server if patient activity,exercise or physiological tests indicate a change that needs attention.

The PPC and/or server may generate reminders to the patient to performsome action, such as take medication, perform a home-based diagnostictest, exercise, or use an external therapy device, e.g., CPAP device.The patient reminders may be based on a particular time schedule that isprogrammed into the PPC, for example, via website or SMS messaging. Insome embodiments, the reminders may not correspond to a schedule but areevent-driven based on the physiological condition of the patient.

In one configuration, the reminders may be conveyed to the patient viathe PPC by a flashing light or vibration. The patient may know fromobserving the flashing light or vibration that it is time to take someaction, such as take medication or perform a home-based physiologicaltest. More sophisticated communication with the patient may beaccomplished by using the flashing light or vibration to notify thepatient to check a website where additional information can bedisplayed. In one approach, a laptop, PDA, cell phone or iPod, forexample, can provide an extended interface for the PPC that can be usedto identify drugs (by picture) and instruct the patient when to take thedrugs.

Unless the patient has mobile internet service, when an active patientis away from home or office, accessing a website may not be possibleimmediately or within a short time after receiving a flashing light orother indicator from the PPC. If the PPC does not have a keypad ordisplay, the user interface of the patient's cell phone may be used tofacilitate interaction between the patient and the PPC. The display ofthe patient's cell phone can be used to display additional informationfrom the PPC while the patient is mobile and cannot access aninternet-connected computer. Communication between the PPC and thepatient may be accomplished, for example, via SMS messaging between thepatient's cell phone and the PPC.

For example, while the patient is out and about, he or she may receivean SMS message on her cell phone that it is time to take one or moremedications. The patient may respond via SMS message to the PPC orserver after taking the meds, allowing the PPC or server to track thepatient's medication schedule compliance and the patient's medicationinventory.

The PPC or server may be programmed to remind the patient to refillmedications or may automatically contact the patient's pharmacy torequest a refill when the patient's inventory of medication is low. Forexample, the PPC may provide a perceptible stimulus (light, sound orvibration of the PPC) or the PPC or server may send an SMS message oremail to the patient reminding the patient to refill medications. Inanother example, the PPC or server may send an SMS message or email tothe patient's pharmacy indicating that a refill is needed. Telephonenumbers and/or email addresses for the patient, the patient's advocate,physician, pharmacy and/or other services may be programmed into the PPCvia cellphone or website. The patient may initiate a call to thepatient's pharmacy or other services by pressing a button on the PPC.

In some situations, it may be beneficial for reminders and/or othermessages to be communicated to the patient by voice message. The PPC mayinclude a speaker so that voice messaging can be used. For example, thepatient's physician or advocate may record a voice message directed tothe PPC. The patient, upon observing a flashing light or other indicatoron the PPC, presses a button that causes the voice message to bedelivered via the PPC speaker and listens to the voice message from thephysician or patient advocate. Alternatively, the flashing light orother perceptible stimulus may serve as an indicator that a web siteshould be accessed to retrieve the voice message or text message. Inanother configuration, the voice message may be sent to the patient'scell phone or land line voice mail box.

FIG. 6 is a flow diagram illustrating an exemplary set of interactionsthat may occur between the patient and the PPC, the APM server, andother services accessible via the PPC. The patient, the patient'sadvocate, or health care professional programs 601 the PPC via a websiteor SMS messaging to generate reminders for the patient, track patientcompliance, and initiate prescription refills. In accordance with thepatient's medication schedule, the PPC sends 602 reminders to thepatient, e.g., via SMS message delivered to the patient's cell phone, orby a perceptible stimulus generated by the PPC shortly before thescheduled time for the patient to take medication.

The patient takes the medication and confirms 603 that the meds weretaken, e.g., via SMS messaging from the patient's cell phone to the PPC,by pressing a button on the PPC, or via interaction with a website. ThePPC keeps track 604 of the patient's medication schedule complianceand/or the patient's medication inventory. The PPC may be programmed tosend an SMS message or email to the patient's pharmacy to orderprescription refills. The PPC or APM updates 605 the patient's personalwebsite that tracks the patient's compliance with the medicationschedule.

The PPC may also be used to help the patient comply with an exerciseschedule or to perform scheduled physiological tests such as weightand/or blood pressure tests. According to the patient's exercise and/ortest schedule, the PPC sends 606 reminders to the patient shortly beforethe scheduled time to exercise or perform the test. The PIMD senses 607the patient exercise and verifies exercise schedule compliance. Theoutput from physiological testing equipment, such as a weight scaleand/or blood pressure cuff, may be coupled to the PPC directly orthrough another device such as the PPC docking station, for example.When the patient performs the scheduled physiological tests, the PPCverifies compliance with the physiological test schedule. The PPC or APMserver updates 605 the patient's personal website that tracks thepatient's compliance with the exercise or physiological testingschedule. The PPC may message the patient's advocate or physician if thepatient's exercise/activity has decreased significantly, or if thepatient's physiological tests are out of range.

The physician may require the patient to assume various positions forcertain diagnostics. In one approach, the physician talks to the patientover the phone, and real-time EGM and other data is streamed to the APMserver via the PPC for presentation on the APM server web site. In thismanner, the physician can collect the desired data for each necessarypatient position. Alternatively, positioning instructions can becommunicated to the patient via the APM server web site or broadcast tothe patient over a speaker provided on the PPC. The patient follows theinstructions, and data is collected by the PPC. This data can becommunicated in real-time or at a later time (e.g., during off-peaktimes).

PPC Employing External Noise Detection

According to some embodiments, the PPC may be equipped with circuitry tosense magnetic and/or electromagnetic leaks or fields as noise that canpotentially interfere with PIMD operation (e.g., falsely sensing anexternally generated e-field or b-field as a tachycardia event andattempting to treat the falsely detected event). For example, detectorsused in stores for detecting active merchandise sensors for theftcontrol may undesirably interfere with PIMD operation. The PPC can beconfigured to sense such externally generated fields and, when detected,transmit a signal to the PIMD indicating that a shock or other cardiacelectrical therapy is not to be delivered because of the “noise”detected by the PIMD.

In another approach involving the APM system 850, and with referenceagain to FIG. 9A for example, the “noise” data sensed by the PPC 800 andthe PIMD data may be uploaded or streamed to the APM server 850, and theAPM server 850 can assess these data and determine whether any PIMDaction is required. The PPC 800 may provide a visual, audio, or tactileindication to the patient that the patient has entered a “bad area” inwhich extraneous and problematic noise has been detected. The indicatormay continuously alert the patient with the “bad area” warning until thepatient has left the “bad area,” which results in termination of thewarning. As was discussed previously, a dashboard application may allowan authorized user to command the PPC 800 to effect a scan of the PPC'slocal environment for RF interference. Data acquired from this scan canbe shown on an “interference” indicator of the dashboard.

Various medical diagnostic procedures may require that the PIMD 802switch to a “safe mode” of operation, which typically involvescontinuance of basic necessary functions and temporary discontinuance ofextra features. For example, a patient with a pacemaker or ICD mayrequire an MRI or other procedure that can adversely interfere with PIMDoperation. The PPC 800 may send a command signal to the PIMD 802 toswitch to a safe mode, such as a magnet mode of operation, for theduration of the diagnostic procedure, during which temporary settingsare typically used by the PIMD 802. For example, the PPC 800 may beenabled by the APM server 850 to command the PIMD 802 to switch to thesafe mode. After completion of the diagnostic procedure, the PPC 800 maytransmit a command to cause the PIMD 802 to switch to a normal operatingmode. Transmission of this command from the PPC 800 to the PIMD 802 maybe instigated by communication of a command from the APM server 850 tothe PPC 800. As a fail-safe, a timer that is set to expire well aftercompletion of a typical diagnostic procedure (e.g., 2-4 hours) may beused to ensure that the PIMD 800 switches back to a normal operatingmode.

Patient Incentives to Use the PPC

Some patients having a PIMD may be relatively mobile and healthy,leading them to be less cognizant of the need to carry the PPC to allowfor periodic or event-driven communication to the APM server. For thesepatients, it may be desirable to provide various incentives to encouragethem to keep the PPC charged and/or to carry the PPC with them as theygo about their daily activities. The PPC may be made more attractive tothe patient by making “skins” for the PPC case available, allowing thepatient to personalize the PPC in accordance with a particular interestor aesthetic taste. The PPC skins may additionally serve as a mechanismto identify the PPC as the patient's device, avoiding inadvertentexchange of the patient's PPC with the PPC of another patient.

The form factor of the PPC allows the PPC to be carried easily carried,and may include a clip, a lanyard, or other attachment mechanism. ThePPC may be configured to clip or otherwise attach to an object that thepatient always or usually carries, such as the patient's cell phone,watch, or other object.

The PPC may include functional features that provide incentives for thepatient to carry the PPC. As described herein, the PPC may generatereminders to the patient in accordance with the patient's medicationschedule, exercise schedule, or physiological testing schedule. If thepatient finds these reminders to be useful, the feature may incentivizethe patient to carry the PPC.

Another example of enhanced PPC functionality providing patientincentives involves the use of the PPC as an exercise or activitymonitor. Many people are interested to know how many calories they burnas they exercise or go about their normal daily routine. The PPC mayprovide this type of feedback to the patient, thereby producing anincentive to the patient to keep the PPC charged and carry the PPCduring day-to-day activities. For example, accelerometer data acquiredby the PIMD and relayed to the PPC may be converted to calories,metabolic equivalents (METS) or other convenient units that the patientcan use to track their activity level. Additionally, a pedometer may beprovided on the PPC itself to measure the number of steps taken or mileswalked or run during the day. The information can be communicated to thepatient via website, or by SMS message from the PPC.

Remote Programming

The ability of the PIMD-PPC pair to provide event-driven updates,real-time waveform viewing and nearly instantaneous command access tothe PIMD for modifying device parameters facilitates remote testing andremote PIMD programming through the LCN. Although remote PIMD testingand programming for various therapy parameters can be envisioned,remotely commanded capture threshold testing and remote programming forpacing energy are used as illustrative examples. Remote programmingpreferably involves a ping from the PPC to indicate to the PIMD that thePPC is close to patient's chest and ready to perform remote programming.

FIGS. 7A and 7B show a flow diagram illustrating remote capturethreshold testing and pacing energy programming via the PIMD-PPC pair.The PIMD monitors paced cardiac cycles that do not produce capture anddetects loss of capture (LOC) after a predetermined number ofnon-captured pacing cycles. The PIMD sends 701 an event-driven LOCnotification to the APM server. The patient's physician observes 702 theLOC notification from a remote site. The physician remotely accesses 705the PIMD via the PPC to determine if conditions are appropriate forperforming a capture threshold test. If so, the physician sends 710 anSMS message command to the PPC initiating the capture threshold test.The PPC receives 715 the SMS message command and relays the command tothe PIMD. The PIMD begins 720 the capture threshold test. During thethreshold test, the PIMD-PPC pair streams 725 real-time EGM waveforms tothe APM server and the physician observes the EGM waveforms from theremote site.

After threshold testing is complete, the APM system analyzes 738 thethreshold test data from the PIMD and may suggest a pacing energymodification. The physician confirms 740 the pacing energy modificationor selects another pacing energy. An SMS command is sent 745 to the PPCto change the pacing energy of the PIMD. The PPC relays 750 the pacingenergy command to the PIMD. The PIMD changes 755 the pacing energy tothe value indicated by the physician. If desired, the PIMD-PPC paircontinue 760 streaming EGM data which is observable by the physician atthe remote site. The physician observes 765 the streaming EGM data andconfirms that the pacing energy change is appropriate for the patient.It is noted that these operations may involve real-time pinging from thePPC to the PIMD as a feedback mechanism, and may involve out of bandsignaling during the connection.

A precursor capability to remote programming that does not directlyinvolve changing of PIMD pacing parameters or delivery of therapy isremote programming of PIMD diagnostics. For example, a number of PIMDalerts are typically programmed to provide diagnostics on leads, pulsegenerators, and arrhythmias, among others. When the PIMD detects apredetermined event, the occurrence of this event is recorded as anincrement of binned events associated with a specific alert. When thenumber of binned events reaches a predetermined value, the alert istripped. Attributes of the alerts (e.g., event detected, alert tripcount, etc.) may be modified via remote programming. Other operationsthat can be effected by the physician that do not involve changing ofPIMD pacing parameters or therapy delivery include resetting ofdiagnostic information, clearing faults, clearing buffers, and redoingdetection.

Flexible alerts can be dynamically changed, and the number of alerts cangrow as the patient's specific pathology is more thoroughly investigatedand understood. By way of example, if the patient has atrialfibrillation (AF), then an initial set of alerts (e.g., 6 alerts) aremade available for assessing the patient's AF condition. If a certaintype of AF is detected, such as persistent AF, then additional alerts (9alerts) can be programmed for the PPC that are targeted to enhancepersistent AF detection and evaluation. Groups of alerts can beconfigured for each type of patient condition.

Delivery of inappropriate shocks to treat tachycardia is a significantconcern for patients that have an implanted ICD. Remote programming ofalerts associated with arrhythmia detection by the ICD may be performedby a physician via the PPC in order to better evaluate the patient'scardiac activity and the ICD's detection of same. Tailoring the alertsby use of PPC-enabled remote programming for a specific patient's ICDallows the physician the opportunity to more optimally program the ICD'sarrhythmia detection criteria that directly impacts delivery of shocksto the patient's heart. This can result in a reduction in the number ofunnecessary shocks delivered to the patient, which reduces patientdistress and ICD power consumption. Although it is envisioned that thephysician could modify the ICD's arrhythmia detection criteria remotely(i.e., technically feasible), it may be necessary to use a programmer ata clinic should induction testing be needed.

Another illustrative example of remote programming of a patient's ICDvia the PPC involves physician commanded atrial shock therapy. Aphysician may view a patient's cardiac activity from a remote locationvia the APM server. The patient's PPC may, for example, stream real-timeEGM data to the APM server. Alternatively, the patient can communicateto the physician (via a button push on the PPC or via a phone call) thatan atrial shock is desired.

Should the physician determine that an atrial shock is appropriate, acommand can be generated by the physician's laptop that instructs theAPM server to transmit a command to the ICD via the PPC to initiatedelivery of an atrial shock. The physician may view the patient'scardiac activity to determine if the therapy was successful inconverting the atrial arrhythmia. Patient-initiated atrial shock therapymay also be enabled by providing an appropriate button on the PPC. Itmay be desirable to have the patient step through a sequence of buttonpushes or other steps to ensure that the patient does not mistakenlyinitiate delivery of an atrial shock therapy.

Cooperative communication between the APM server, PPC, and ICD canfacilitate remote programming of a variety of ICD parameters. Forexample, remote programming can allow a physician to change ICDparameters that can improve or optimize shock therapy by modifying oneor both of sensitivity and specificity parameters that influence theICD's arrhythmia detection behavior. Changes to ICD parameters that maybe effected by physician remote programming include increasing shockenergy output, adjusting detection rate, modifying ATP parameters, andadjusting the number and range of detection zones, for example. Thephysician may remotely enable and disable detection enhancements, andmay change parameters of such detection enhancements. In the case of apacemaker or CRT device, the physician may adjust V-V timing, A-Vinteraction with ventricular pacing, and basic lower rate limit or upperrate limit parameters, among others.

Remote programming can involve providing the physician with options forchanging parameters and perhaps providing recommendations for makingchanges, and then allow the physician to manually select parametervalues. In general, the PPC has more data that the PIMD, and thisadditional data may be used by the PPC to make or recommend programmingchanges, similar to the way the PIMD automatically changes certainpacing and therapy parameters.

The additional information available to the PPC, such as from sensorsand the APM server, can be used to optimize changes to pacing andtherapy parameters. This additional programming intelligence provided bythe PPC may be particularly useful in cases where the APM server canbecome overloaded. It can be appreciated, for example, that optimizingpacing parameters by the APM server for thousands of patients may betaxing or infeasible. Offloading some or all of the pacing parameteroptimization burden onto the PPC can significantly reduce the traffic toand from the APM server.

Different workflows may dictate different manners of PPC-APM serverinteraction. When making a programming change to the PIMD, for example,a message can be sent to the PPC, the PPC can establish a “live”connection with the APM server, and the APM server can alter the PIMDprogramming. In a delayed workflow model, such as one involvingquarterly reporting, the physician can take time to make a PIMDprogramming change. In another workflow involving an intermediary, suchas a registered nurse, the RN may visit a nursing home on a quarterlybasis, and be an intermediate between the APM server and a low-levelclinician, such as one at a neighborhood clinic that does not require aphysician.

Prior to, or during, remote programming, the physician may need to knowwhat the patient is doing in order to give context to the data. Forexample, it may be important for the physician to know that the patientis sleeping or engaged in strenuous activity prior to effecting a changeto the patient's PIMD via remote programming. Various physiologic andpatient-condition sensors may be used to determine the present status ofthe patient. Such sensors may be configured to sense one or more ofcardiac electrical activity, cardiac mechanical activity, posture,acceleration or motion, respiration, minute ventilation, neuralactivity, brain activity, and muscle activity, for example. The sensorsmay be external or internal sensors (e.g., intra-body sensor network).

The data produced by the sensors may be transmitted to the PIMD and thento the PPC or directly from the sensors to the PPC. The PPC can streamdata from any of these or other sensor to provide the physician withdata concerning the patient's present condition or status. It may alsobe useful to know if the PPC is mobile or in its docking hub. Voiceoutput from the PPC may be used to time-correlate sensor data (e.g., EGMdata) so that the physician knows what to look for and the patient'sreaction. Also, time stamp data may be appended to sensor data and/or anevent marker may be appended to sensor data that results from patientactuation of a PPC button when an event is felt by the patient.

The above discussion of remote testing to determine capture thresholdand remote programming to set pacing energy illustrates concepts ofremote testing and remote programming which are equally applicable toother therapy parameters. Many applications for remote testing, remoteprogramming, and/or event-driven remote testing and programming can beenvisioned. Streaming data from the PIMD available over the LCN allowsthe physician to observe in real time the progress of testing or theresults of a programming change. Similar approaches for remote testingand programming are applicable to many parameters used for electricalstimulation therapy, such as testing and/or setting A-V delays, V-Vdelays, refractory periods, selection of pacing modes, pacing rates,selection of the heart chamber to pace or the order in which heartchambers are paced, selection of pacing sites within a heart chamber orthe sequence of pacing pulses delivered to the sites, and/or a varietyof other therapy or diagnostic parameters.

Remote programming may be initiated by caregiver action and may end withthe reporting of the success or failure of the application of theprogramming to the intended PIMD back to the caregiver. FIG. 7C is aprocess flow diagram showing a method for remotely programming a PIMD,in accordance with one embodiment. Remote programming is performed as asequence of operations, which, in specific instances, can be suspendedor broken at specific points as necessary.

Initially, a caregiver performs a remote programming session (operation731) through a data entry mechanism. Caregiver-selected programminginstructions and parameters are translated by a regulated server intoPIMD-formatted commands, which are checked for correctness and digitallysigned (operation 732). The PIMD-formatted commands are also reversetranslated and provided to the caregiver in displayable form foracceptance or rejection (operation 733). If the translated programmingis rejected by the caregiver, control reverts back to the caregiverprogramming session (operation 731). Otherwise, the PIMD-formattedcommands are marked for delivery to the server and, following receipt bythe server, are verified for authenticity and integrity (operation 734).

In a further embodiment, the PIMD itself also performs verification ofthe commands, either in addition to or in lieu of the server. Assumingthe commands are verified, the patient consent is confirmed (operation735) prior to application of the commands. However, if the patient doesnot provide consent, control again reverts back to the programmingsession (operation 731). Upon consent, the server performs a programmingsession (operation 736). If the session is interrupted and not resumed,or abnormally terminates, the original PIMD programming is restored andcontrol reverts back to the programming session (operation 731). Uponsuccessful programming, the server interrogates the PIMD followingprogramming session completion to report post-programming results to thecaregiver (operation 737) for review and evaluation. Additionalimplementations for remote programming, aspects of which may be used inconjunction with various embodiments discussed herein, are described incommonly owned U.S. Patent Publication No. 20070185547 and U.S. Pat. No.7,710,648, which are incorporated herein by reference.

PPC with Reduced Feature Set

FIG. 8 shows a PPC 800 paired with a PIMD 802 and communicativelycoupled thereto via a communications link 804. The PPC 800 may beimplemented to provide a wide spectrum of capabilities andfunctionality. Within this spectrum, the PPC 800 may be configured toprovide a variety of features or a limited number of features. In someimplementations, for example, the PPC 800 may be configured to have areduced number of features and capabilities (e.g., a reduced feature setPPC). A PPC 800 configured to have a reduced set of featuresadvantageously reduces the complexity and cost of the device, andenhances acceptance of the device by less sophisticated users. A PPC 800having a reduced set of features also provides for lower powerconsumption, such as by minimizing or eliminating a display or otheruser interface components. The PPC 800 may also be implemented toincorporate a variety of features and capabilities that provide for awide range of functionality, as will be discussed below with referenceto other embodiments.

FIG. 8 illustrates a PPC 800 having a reduced feature set and arelatively small form factor. For example, the PPC 800 shown in FIG. 8may weigh less than about 6 ounces, and be small enough to fit easily ina purse or pocket. The PPC 800 has a simple user interface (U/I), whichis shown to include a single button 801, a small LCD 806 that canprovide basic status information (e.g., date, time, signal strength, andbattery status), and an LED 808. The LED 808 may indicate ON status ofthe PPC 800 or other operational status indication. In oneimplementation, illumination of the LED 808 (or illumination of a greencolor for a multi-color LED 808, for example) may indicate that thePPC's battery is sufficiently charged to provide at least 24 hours (orother duration) of continuous service. The LED 808 may be controlled toimplement a flashing scheme, which may include different colors, thatcommunicates information to the patient. For example, a green ON colormay indicate acknowledgement that interaction with the user wassuccessful (e.g., a quick flash green light).

The button 801 may provide basic functionality, such as for initiatingpatient-interrogated transmissions and pairing/re-pairing procedures.The button 801 may also be actuated by the patient for indicating adistress condition of the patient, to which an emergency service mayrespond (e.g., 911 alert/call). In this regard, the PPC 800 may beconfigured to include a GPS transponder or transceiver, or providelocation information via other approaches used for locating cellularphone users, which may be used to locate the PPC 800 and, therefore, thepatient in an emergency situation. In addition to GPS or other locationinformation, the PPC 800 may communicate patient information obtainedfrom the PIMD 802, which can provide important information about thecondition of the patient (e.g., the patient's vital signs obtainedremotely by the emergency response service/technician, in addition tolocation information).

The PPC 800 may have a reduced feature set that excludes a keypad orother more sophisticated user input device, and may also exclude voicechannel components associated with conventional cellular phones, forexample. The PPC 800, in this configuration, preferably utilizes data orsignaling channels of the cellular infrastructure to facilitatecommunications with remote services and systems.

In some configurations, the button 801 may be a multi-functional button(e.g., contact sensitive switch, multi-state switch or rocker switch).Button activation for controlling PPC functions may include one or moreof a quick click, a double click, and a long hold. A button clickingscheme may be developed to perform a variety of operations, includinginitiating a PIMD 802 interrogation when the patient feels poorly,calling the APM server, and initiating delivery of a pre-configured SMSmessage to pre-determined parties (e.g., physician, neighbors, friends,children, relatives, emergency response service) to alert the recipientthat the patient is in distress or need of attention.

If the PPC 800 detects a condition necessitating a shock and the shockis delivered, the PPC 800 may be programmed to automatically upload datato the APM server, which updates the APM server web site. Detection ofthe event, remedial action taken by the PPC/PIMD, and initiation of theautomatic upload process should be communicated to patient, such as by aflashing LED sequence, so that the patient knows the event has beenaddressed and recorded. In cases where the APM server needs the patientto perform a function using the PPC 800, the APM server may initiate aphone call to the patient, and request that the patient activate anappropriate button click.

The PPC 800 may incorporate a speaker (preferably without a microphonein the case of a reduced feature set PPC 800, but a microphone can beincluded on a more robust PPC configuration). An audible feedbackmechanism may be implemented as another means of communicating with thepatient. The audible output from the speaker is preferably tonal, butvoice output can also be employed. A “quiet mode” can be activated, suchas by a 5 second button hold, to disable the speaker and, if desired,transition to a vibration/silent mode, if the PPC 800 is equipped with avibrator device. The PPC 800 may be programmed to produce tones that canbe used to transfer data via a TTM scheme, which can be a backup way ofcommunicating to the APM server if cellular network service isunavailable. The speaker may produce a beeper sequence that can be usedas a locator (via a button on the PPC's docking hub).

Configurable PPC

A PPC implemented in accordance with embodiments of the presentinvention may be dynamically configurable via interaction with an APMserver and/or a PIMD. This capability of dynamically altering theconfiguration of a PPC serves to enhance cooperative operation betweenthe PPC, PIMD, and APM system.

FIG. 9A shows an illustration of a multiplicity of PPCs 800communicatively coupled to an APM server 850 via a network 830.According to the embodiment shown in FIG. 9A, the APM server 850 iscoupled to a metadictionary 852. The metadictionary 852 storesinformation concerning the various types of PIMDs that are supported bythe APM server 850. For example, the metadictionary 852 may storedetailed information about the serial number, make, model,software/hardware, features, device type or family, etc. about each PIMDthat is supported by the APM server 850. The metadictionary data, inshort, identifies the capabilities of each PIMD of the system. Thisinformation has a number of uses, such as facilitating dynamicconfiguring of the PPCs 800.

According to one approach, a PPC 800 is paired with its correspondingPIMD 802, such as the paired devices shown in FIG. 8. The PPC 800preferably receives identification information from the PIMD 802 thatuniquely identifies the PIMD 802, such as the model and serial number(e.g., concatenated or combined) of the PIMD 802. The PPC 800 may thencommunicate this identification information to the APM server 850, whichaccesses the information for the particularly PIMD 802 stored in themetadictionary 852. Using this information, the APM server 850 may senddata to the PPC 800 that configures the PPC 800 to cooperatively operatewith the PIMD 802 in accordance with the metadictionary data. In thismanner, an “off-the-shelf” PPC can be dynamically configured for usewith a particular PPC during a pairing operation via the APM server 850.

For example, the metadictionary data for a particular PIMD 802 mayinclude power capacity and consumption data for the PIMD 802. Inresponse to this data, the PPC 800 may adjust the manner in which iteffects communications with the PIMD 802, such as by increasing ordecreasing the frequency of non-life critical data from the PPC 800 tothe PIMD 802 for transfer to the APM server 850. Various datacompression schemes may be used to reduce the volume of data transferredbetween the PIMD 802 and the PPC 800. In one approach, a number of datacompression schemes are available for effecting data transfer betweenthe PIMD 802 and the PPC 800. Metadictionary data may be communicatedfrom the APM server 850 to the PIMD 802 for purposes of substituting ormodifying the data compression scheme used by the PIMD 802 and/or PIMD802, such as for power conservation purposes or for enhancingcompatibility with the particular networking protocol.

By way of further example, metadictionary data may be transferred fromthe APM server 850 to the PPC 800 that modifies a data interrogationroutine of the PPC 800, thereby altering the type (and format, ifappropriate) of data to be acquired from the PIMD 802 by the PPC 800.This may be particularly useful when conducting research or developingclinical trial protocols. The type of data to be acquired from the PIMD802 of a particular patient may change as the patient's status (e.g.,heart failure status or tachyarrhythmia status) changes over time. Thevolume of data acquired from the PIMD 802 and/or timing of datatransfers may be modified using the PPC 800 in response tometadictionary data received from the APM server 850.

The PPC 800 may also receive a decoder ring associated with its pairedPIMD 802 from the metadictionary 852 via the APM server 850. A decoderring is associated with the particular decoding scheme or logic used bya type or family of PIMDs. Every PIMD has a unique decoding scheme thatis identified by the decoder ring associated with the particular PIMD.The decoder ring for a particular PIMD 802 may be transferred from theAPM server 850 to the PPC 800 that is paired with the particular PIMD802. For example, the decoder ring for a particular PIMD 802 may bestored in a SIM card of the PPC 800. Transferring the decoder ring tothe PPC 800 at the time of pairing with its associated PIMD 802advantageously allows a “generic” PPC 800 to be used for effectingcommunications between a wide variety of PIMDs and the APM server 850.

Firmware of the PPC 800 may be updated by the APM server 850. Forexample, the metadictionary 852 may identify a number of PPCs 800 thatrequire a particular change in firmware. Version updates and patches maybe distributed by the APM server 850 to appropriate PPCs 800 identifiedby the metadictionary data. By way of further example, communicationsfirmware updates may be distributed to appropriate PPCs 800 to updatethe PPCs 800 capability to communicate over one or more cellularnetworks as such networks evolve over time.

In some configurations, the PPCs 800 may incorporate a multi-band radio,such as a quad-band radio. The PPCs 800 may also include multipleshort-range radios, such as ISM and SRD radios). The PPCs 800 may switchto different radios depending on the geographical location of the PPCs800 and the available cellular service (e.g., when traveling from the USto Europe). The PIMD 802 may also change radios, such as in accordancewith radio changes made by the PPCs 802 (e.g., ISM to SRD). The PPCs 800may also include an inductive coil that can be used to establish anauxiliary or backup link between the PPCs 800 and the PIMD 802. In thisregard, the PPCs 800 may be used in the similar manner as a conventionalwand.

According to one implementation, PPCs 800 may incorporate a softwaredefined radio (SDR) device or module (permanent or replaceable) that canbe configured to dynamically define and redefine the communicationscapabilities of the PPCs 800. An SDR device is a radio communicationsdevice that can be programmed to tune to any frequency band and receiveany modulation across a large frequency spectrum by means ofprogrammable hardware which is controlled by software.

According to one implementation, the hardware of an SDR incorporated inthe PPC 800 may include a superheterodyne RF front end that converts RFsignals from and to analog IF signals, and an analog-to-digitalconverter and digital-to-analog converters which are used to convert adigitized IF signal from and to analog form, respectively. An SDRperforms signal processing using a generally purpose CPU or areconfigurable piece of digital electronics. Incorporating an SDR in thePPC 800 advantageously provides for a radio that can receive andtransmit a new form of radio protocol simply by running new softwarethat can be distributed to the PPC 800 from the APM server 850. An SDRmay be configured to operate with different modalities, including shortrange modalities (e.g., Bluetooth, Zigbee, FM) and long range modalities(e.g., RF telemetry utilizing MICS, ISM or other appropriate radiobands). A more advanced SDR may support multiple communicationsmodalities as selected by the PPC 800 or APM 850. These variousmodalities typically differ in terms of power consumption andtransmission range, and may be programmed, enabled, and/or selectedbased on these and other considerations.

PPC Diagnostics

The PPC 800 preferably has a “Built-In Self Test” mode for performingvarious diagnostics. Because the PPC 800 preferably has at least tworadios (e.g., cellular and ISM/SRD), these radios may be used to performvarious diagnostics. For example, one radio of the PPC 800 can be usedto transmit over a network connection, and the other radio can listenand verify that the received power is as expected. The same can berepeated, but with the two radios swapping transmission and receptionroles. This test can be done at a reduced power mode and at a frequencyof interest as the RF regulations allow. Also, the cellular radio getsinformation back from the tower about the PPC signal strength at thetower, and the PPC 800 sees the power of the tower signal as received.

By way of example, the transmitter of a first radio of the PPC 800 maybe set to a frequency which a second radio of the PPC 800 can receive. Asignal transmitted from the first radio is coupled to the second radiovia the PPC's antenna system or via an RF coupler, an RF switch, or anattenuator. A simple diode receiver can also be used to provide a secondmeasurement of transmission power to eliminate ambiguity. The preferredapproach is to use the PPC's existing antenna system so that thecomplete RF path can be verified.

Functional testing may be performed using a first configuration by whichthe first radio operates as a transmitter and the second radio operatesas a receiver. Functional testing may be performed using a secondconfiguration by which the second radio operates as a transmitter andthe first radio operates as a receiver. According to one approach,functional testing is performed using one of the first and secondtesting configurations to detect a performance deficiency, andfunctional testing is performed using the other of the first and secondconfigurations only in response to detecting the performance deficiency.Functional testing may be terminated (and a message generated) upondetecting a performance deficiency using only one testing configurationin order to preserve PPC and/or PIMD power. A detected performancedeficiency may be verified using the other testing configuration ifdesired.

The transmit power/receive sensitivity can be measured, data ormodulation can be verified, and frequency accuracy can be measured byvarying either or both of the receiver and transmitter frequency. Out ofband rejection can be measured also by varying the transmitter frequencyto a known “out of band” frequency. This testing approach may beperformed or repeated by using the second radio as the transmitter andthe first radio as the receiver.

If PPC location information is available, the data may be stored on theAPM server to verify that the PPC 800 is the same one that performedprevious tests from that location. If the ISM/SRD radio is used to scanthe local environment and again using location information, it ispossible to verify that the environment is still favorable for PIMD datatransmission or when that location is clean for such traffic. Thisprovides a mechanism to optimize connections for PIMD data traffic.

A appropriate pause in PIMD telemetry may be necessary to allow thecellular connection to remain alive. This is needed so that a ping canget through and the cellular connection stays open, to stay connectedvia the tower or to keep a communication session open. If necessary, itmay be useful to briefly hold off PIMD communication during an opensession to allow the cellular connection to stay associated with itstower as required. Also, PIMD communication can be adjusted tointerleave an active cellular data call so that both can be active indifferent time slots. This would allow use of a common antennamultiplexed between the two radios when both are active.

Streaming data may be accomplished by operating in a burst mode(intermittent mode). For example, data is first transmitted from thePIMD 802 to the PPC 800 via ISM/SRD/MICS, and then to the cellularnetwork. According to another approach, it is possible for the cellularradio of the PPC 800 to communicate directly with the PIMD'stransceiver. This can be accomplished by pushing a communicationsprotocol stack to the processor of the cellular radio of the PPC 800 toaccess the ISM, SRD, or MICS radio bands.

When traveling abroad, the PPC 800 is configured for use in accordancewith its physical location. This may involve setting the ISM/SRD radiobands based on cell phone frequency. Also, the PPC 800 adjusts to ensurecompliance with privacy requirements for each location. In Japan, forexample, this may involve turning off/on the RF radio based uponlocation as determined from a cell tower (or absence of a tower).

Expanded PPC User-Interface Using Separate Communications Device

FIG. 10 illustrates a PPC 800 configured with a reduced feature set, asdiscussed above. Although the PPC 800 shown in FIG. 10 may have aminimum of features, enhanced user interface capabilities may beprovided via cooperation between the reduced feature set PPC 800 and awireless (or wired connected) device configured to communicate with thePPC 800. For example, the PPC 800 may be configured to communicate withone or more local devices, such as cellular phones 908, portablecomputers 902, personal digital assistants (PDA) 906, digital musicplayers 904, tablet computers 910, or any other device represented bygeneric device 912. Many of the user interface/user input facilities(e.g., LCD displays, keypads, mouse, stylus) provided by these devicesmay allow the patient or clinician/caregiver to interface with the PPC800, as if these facilities were otherwise built into the PPC 800 andAPM server 850. For example, data and graphics indicative of physiologicsignals and information may be presented on a display of such localdevices. The patient may also interact with the PPC 800 via the userinterface devices of a local communication device (e.g., PC or PDA) viaa hub or docking station configured to cradle the PPC 800, such as thatshown in FIG. 14.

Expanded interfacing capabilities between the PPC 800 and externaldevice(s) may be effected with or without involvement of the APM server850. For example, the local interfacing device (e.g., laptop) maycommunicatively couple wirelessly or via hardwire connection (e.g., USBor FireWire) with the PPC 800 and acquire data from the PIMD 802. Thelocal device may display various types of data acquired from the PIMD802, such as ECG waveforms, sensor data, event counters, histograms, andother information of interest. Generally, view-only access to the PIMDis preferably granted to local devices such as those shown in FIG. 10.It is noted that an appropriate local device, such as a laptop, may beconfigured to emulate a PIMD programmer, and that an authorizedclinician may interrogate or program the PPC 800 locally using suchlocal device. The data associated with local PIMD programming and/orinterrogation may be uploaded to the APM server 850 via a wirelessconnection or hardwired connection.

This system configuration is particularly useful in the context ofemergency response, such as by allowing ambulance EMTs the capability toevaluate PIMD information for a patient that may be impaired, distressedor unconscious, for example. The local device may also be configured tointerface with the APM sever 850, and may effect a life-criticalconnection between a clinician communicating via the APM server 850 andthe local device via PPC 800. In an emergency room scenario, PIMD datamay be transferred to a laptop or other computer system in the ER toallow physicians to quickly evaluate real-time and stored physiologicdata for the patient.

Emergency Calling and Response

It may be important to ascertain the present location of a patient whomay be in distress or requires emergency attention. The PPC 800 may beused to locate the patient, such as by using a known triangulationlocating technique that uses the PPC 800 and a multiplicity of celltowers. Such techniques may determine the location of the PPC 800 bymeasuring and comparing signal strengths or other parameter of signalscommunicated between the PPC 800 and a multiplicity of cell towers.Preferred techniques are those that do not require additional PPChardware, such as an additional dedicated antenna or a GPS or othersatellite receiver, for example. It is understood, however, that someembodiments may include such additional components.

Various known techniques may be employed to locate the PPC 800 and,therefore, the patient (or provide a good estimate of patient location).Examples of PPC location techniques that may be employed in accordancewith embodiments of the present invention are disclosed in U.S. Pat.Nos. 5,293,642; 5,873,040; 6,088,594; and 6,477,363, all of which areincorporated herein by reference.

The PPC 800 may be configured to initiate an emergency call forassistance, such as by initiating a 911 call. The PPC 800 may beprogrammed to automatically place a 911 or other emergency call based onpredetermined conditions, such as when the PIMD 802 detects apotentially life-threatening condition (e.g., VT, VF, asystole,abnormally low or absent respiration rate) and communicates thiscondition to the PPC 800. Classes of events that, if detected, warrantimmediate initiation of a 911 or other emergency call include: 1)myocardial infarction; 2) prediction of myocardial infarction; 3)pre-event identification of a serious or life-threatening upcomingevent; 4) VF/SCD (sudden cardiac death); and 5) specific request by thePPC 800 (via an indicator or synthesized voice message broadcast via aPPC speaker) to call 911 and, if applicable, a request for use of an AEDor CPR on the patient. In some embodiments, the patient's cardiac rhythmacquired by the PIMD 802 may be transmitted to the PPC 800 which thenbroadcasts the patient's rhythm to help an emergency respondersynchronize chest compressions during delivery of CPR. The PIMD 802 mayattempt to initiate an autocapture procedure in an attempt to increasethe patient's heart rate during attempted resuscitation, and an audibleor visual alert may be generated by the PIMD in the event that the PIMDcannot effect capture and to indicate that immediate assistance isneeded.

The patient may be permitted to initiate a 911 or other emergency call,such as by actuation of a button reserved for emergencies on the PPC800. In cases where an emergency call is manually initiated by thepatient, the PPC 800 may be programmed to verify presence of a patientcondition warranting an emergency response. For example, the PPC 800 mayinterrogate the PIMD 802 prior to initiating an emergency call inresponse to patient actuation of an appropriate “emergency” button. Thelocation of the PPC 800 may also be determined using triangulation orother technique discussed herein, and the PPC 800 may communicate withthe PIMD 802 as a confirmation that the computed or estimated locationof the PPC 800 is where the patient actually is.

Upon verifying presence of a patient condition warranting an emergencyresponse, the PPC 800 initiates a 911 or other emergency call. As partof the PPC's emergency protocol, the PPC 800 may initiate a call to thepatient's home phone or other advocate's phone to provide status to thepatient's family or advocate after placing the emergency call. A callmay also be made to the APM server 850, which may provide voiceinformation as well as patient data, printouts, real-time ECG and otherinformation to the EMT, ambulance, and/or hospital that is useful fortreating the patient. This data may include, for example, the patient'sdrug regimen, allergies, recent medical evaluation data, physicianinformation, and medical ID information.

In response to the PPC 800 determining that the patient condition doesnot warrant an emergency response based on the PIMD information, the PPC800 may indicate to the patient that, although a request for emergencyservices has been requested by the patient, the condition does notwarrant initiation of a 911 or other emergency call. The patient may begiven the opportunity to manually initiate the emergency call afterconsidering this information from the PPC 800, notwithstanding the“recommendation” by the PPC 800 that such emergency attention is notwarranted based on the PIMD information. These features can aid inreducing false-alarms and unintended and/or unnecessary calls to 911services or other emergency service providers.

According to other embodiments, the APM server 850 may implement anemergency response methodology in response to information received fromthe PPC 800. The APM server 850 may first determine if the PPC 800 ispaired with its associated PIMD 802. According a tiered responseapproach, the APM server 850 may assess PPC information and determinethe level of patient risk. Based on the level of patient risk, the APMserver 850 may take appropriate action. For example, the APM server 850may determine the patient is at high risk and that immediate attentionis warranted. For high risk situations, the APM server 850 may initiatea 911 or other emergency call. The APM server 850 may also initiate apatient location assessment using the PPC 800 and cellularinfrastructure (or other technique as discussed herein) to locate thepatient. This patient location assessment may also be initiated orrequested by the emergency response service.

In medium risk situations, the APM server 850 may take time to evaluatethe various data available for assessing the patient's presentcondition. This may involve acquiring additional PPC data, such assurface ECG or EMG data, and/or running particular algorithms toevaluate patient condition and the patient's risk level. Medium andlower risk situations may be resolved by communicating assessmentinformation to the patient via the PPC 800 or by follow-up phone call(automated or personal) or other messaging resource. For example, thePPC 800 may provide “reassurance” or validation information to thepatient that emergency services are needed or not needed, and/or toinstruct the patient to contact the patient's physician or an emergencyroom, for example.

In some embodiments, the PPC 800 is programmed to evaluate patient riskbased on all available information it has received from the PIMD 802and/or the APM server 850. The PPC 800 may implement a similar protocolas discussed above for the APM server 850. For example, the PPC 800 maycollected data from the PIMD 802 and determine the number of shocksdelivered over a given time period. Based on the number of shocksdelivered within a specified time range, the PPC 800 may distinguish ahigh risk situation from a medium risk salutation. If, for example, thePPC 800 determines that three shocks were delivered within the last 3minutes, the PPC 800 may consider this a high risk situation andinitiate a 911 call. If only a single shock has recently been delivered,then this event and the medium to low risk associated with it can becommunicated to the patient in some form to reassure the patient. Forexample, this data and other relevant information may be communicated tothe patient via a voice synthesizer and speaker provided in the PPC 800.In either situation, this data is preferably communicated to the APMserver 850.

In other embodiments, the PIMD 802 is programmed to evaluate patientrisk based on all available information it has acquired from the patientand/or received from the PPC 800 and/or the APM server 850. The PIMD 802may implement a similar protocol as discussed above for the APM server850, and cooperate with the PPC 800 and/or APM server 850 to implementan appropriate response protocol.

It is noted that real-time monitoring is preferably implemented duringhigh and medium risk situations. During such situations, the datacollected from the PIMD 802 may be dynamically changed to accommodate anincreased or decreased need for PIMD data. Dynamically adjusting thetype and quantity of PIMD data needed to evaluate a patient's conditionis preferably implemented to conserve PIMD power, it being understoodthat this approach to changing the type, quantity, and frequency of PIMDdata may be implemented in other situations in order to optimize PIMDpower conservation.

PPC and APM System

FIG. 11 illustrates various types of PIMD data that can be transferredfrom a PIMD 802 to a PPC 800, from the PPC 800 to an APM server 850, andfrom the APM server 850 to the clinician or other user. As is depictedin FIG. 11, various physiological data acquired by the PIMD 802 aretransferred to the PPC 800. This data may be transferred by the PIMD 802to the APM server 850 in real-time mode or batch mode. For example,occurrence of a predetermined event may trigger a data transferoperation from the PIMD 802 to the PPC 800. Based on the criticality ofthe event, the event data may be temporarily stored in the PPC 800 forlater transmission to the APM server 850, in the case of less criticalevents. In the case of critical events, immediate connectivity may bemade between the PPC 800 and the APM server 850, and PIMD data may becommunicated to the APM server 850 in real-time (e.g., real-timestreaming of PIMD data from the PIMD 802 to the APM server 850 via thePPC 800). It is understood that the term “real-time” connotes a mannerof communicating data as fast as is practicable from a transmissionsource to a receiving device given real-world (i.e., non-ideal)technological practicalities, such as connection and transfer delays,among others.

In accordance with embodiments of the present invention, PIMDinterrogation, programming, data transfer operations (e.g., incrementaldata transfers), and query/response protocol operations need not besubject to a predefined schedule (e.g., between nighttime hours of 1-3AM), but may be event based. Events detected by the PIMD 802 or actionsinitiated by the patient (e.g., pushing a button on the PPC 800) maytrigger cooperative operation between the PIMD 802 and PPC 800 orbetween the PIMD 802, PPC 800, and the APM server 850. Certain eventsmay trigger real-time connectivity between the PPC 800 and the APMserver 850, while others may trigger store-and-forward data transferoperations. It is noted that it may be desirable to limit patientinteraction with the PIMD 802 in non-critical situations, such as forconserving battery power.

Cooperative operation between the PIMD 802, PPC 800, and the APM server850 provides for a number of useful real-time capabilities. For example,real-time monitoring of patients by remotely located clinicians may berealized, which may include real-time waveform display, real-timephysiological monitoring for remote triage, real-time physiologicalmonitoring and display at a remote clinician location, and real-timeleadless ECG waveform viewing. Real-time clinical alerts for high riskpatients may be generated at a remote location in response topredetermined patient events. Patient data may be streamed to the APMweb site and displayed within a browser plug-in, which may includesmoothed anti-aliased display of physiological waveforms at 24 framesper second or higher. In this regard, cooperative operation between thePIMD 802, PPC 800, and the APM server 850 may facilitate implementationof an “always on” or at least an “always available” life criticalnetwork when the PPC 800 establishes a network connection.

FIG. 11 shows data transferred from a PIMD 802 and PPC 800 to a website940 supported by an APM server 850. Data acquired from the PIMD 802 maybe organized in the manner shown in FIG. 11, an expanded view of whichis shown in FIG. 12A for illustrative purposes. Data acquired from thePIMD 802 and stored in the APM server 850 may be transferred to, andincorporated within, an electronic medical records system 945, summarydata from which is shown in FIG. 12B for illustrative purposes andadditional details of which are disclosed in commonly owned U.S. PatentPublication No. 20070226013, which is incorporated herein by reference.

FIG. 11 also shows real-time PIMD 802 data displayed graphically. Inthis illustrative depiction, real-time EGM data for multiple channels(RV, atrial, and shock channels) is displayed. Atrial and ventricularrates, along with other data, may also be displayed. Date regarding thepatient, device mode, programmer mode, and the PIMD 802 may bedisplayed. Detailed data 955 concerning the PIMD 802 may be displayed inreal-time and/or output in report form, an example of which is shown inFIG. 12C for illustrative purposes.

PPC Communications Interfaces

The PPC 800 preferably incorporates a built-in transceiver that may beconfigured to establish bi-directional communication with a networkutilizing various known communication protocols, such as those used incellular networks. The PPC 800 also incorporates a short rangetransceiver for establishing a local communication link 804 between thePPC 800 and PIMD 802, and, in some embodiments, between the PPC 800 andone or more sensors disposed on the PPC 800 (or other patient sensors inproximity to the PPC 800). The local communication link 804 may beestablished in accordance with a variety of known protocols, such asMICS, ISM, or other radio frequency (RF) protocols, and those thatconfirm to a Bluetooth standard, IEEE 802 standards (e.g., IEEE 802.11),a ZigBee or similar specification, such as those based on the IEEE802.15.4 standard, or other public or proprietary wireless protocol.

The PPC 800 may incorporate a communications port 814 that may beconfigured to receive a connector for a hardwire communication link. Insuch a configuration, a conductor (electrical or optical) may beconnected between the hardwire connector or communication port 814 ofthe PPC 800 and an appropriate connector of a patient-external system,such as a laptop. The hardwire connection port 814 of the PPC 800, andany necessary interface circuitry, may be configured to communicateinformation in accordance with a variety of protocols, such as FireWire™(IEEE 1394), USB, or other communications protocol (e.g., Ethernet). Itis understood that various hardwire connection protocols allow for thetransmission of power in addition to data signals (e.g., USB), and thatsuch connections may be used to recharge an internal or backup batterysource 812 of the PPC 800.

PPC Power Features

According to various embodiments, the PPC 800 may include a rechargeablebattery 821 having a relatively high capacity. For example, therechargeable battery 821 of the PPC 800 may have a capacity of 1200milliamp hours (e.g., 120 days standing time, 8 hours transmission). ThePPC 800 may include a secondary battery 812 as fail-over mechanism or toincrease the capacity of the battery resources of the PPC 800. Incertain configurations, the PPC 800 may include a capacitor or batterythat is rechargeable by turning a crank that turns a dynamo coupled tothe capacitor or battery. The PPC 800 may incorporate an integral crankor a socket that receives an integral or detachable crank. Other manualrecharging mechanisms may include a generator coupled to a displaceablemass.

Various kinetic energy harvesting mechanisms may be incorporated thatharvest kinetic energy resulting from PPC movement which can be storedin a battery of the PPC 800. Patient movement of the PPC 800 fromwalking, for example, may cause movement of a displaceable mass thatmechanically activates a generator, which converts the kinetic energyimparted by the displaceable mass to a DC recharge signal. The PPC'sbattery may be recharged inductively, such as by use of a tank circuit.A manual or automatic-mechanical recharging capability may beparticularly useful in regions of the world that have sparse orunreliable power distribution systems. The PPC 800 preferably generatesan alert to indicate when main rechargeable battery 821 power is low.

Management of the PPC's battery status may be monitored and managed viathe web site of the APM server (e.g., via a dashboardapplication/interface). PIMD battery life may be optimized or extendedby properly coordinating data transfers between the PIMD 802 and the PPC800. It is known that a significant amount of PIMD power is consumedduring active use of the wireless transceiver of the PIMD 802. Thisusage of power may be reduced or optimized by proper coordination of thedata transfer operations between the PIMD 802 and PPC 800. According toone approach, predefined clinical events as detected by the PIMD 802 maybe categorized in terms of criticality. The manner in which dataassociated with these events is transferred from the PIMD 802 to the PPC800 may be dependent on the level of event criticality. For example,data associated with less critical events may be transferred to the PPC800 with less frequency than data associated with events of highercriticality. Real-time connectivity between the PIMD 802, PPC 800, andAPM server 850 may be reserved for events of highest criticality, suchas life-threatening tachycardia events (e.g., VT or VF episodes). Datafor less critical events may be batch transferred, for example, toreduce power consumption by the transceiver of the PIMD 802.

Managing PIMD Power Using High Frequency Polling

According to some embodiments, the PPC 800 may be programmed toimplement a high frequency polling protocol that effects necessaryinterrogations of the PIMD 802 while doing so in power efficient manner.High frequency polling according to embodiments of the present inventioncan be viewed as simulating event driven pushes by the PIMD 802 by highfrequency polling by the PPC 800. It is understood that the term “highfrequency” as applied to polling by the PPC 800 refers to the number oftimes (e.g., frequency of occurrence) the PPC 800 polls the PIMD 802within a specified time period. A high frequency polling approach of thepresent invention may be implemented to acquire necessary data from thePIMD 802 in a power efficient manner. For example, a high frequencypolling approach of the present invention may be implemented tofacilitate acquisition of a requisite volume of timely data from thePIMD 802 to address the patient's present condition while using aslittle PIMD power as is practicable under present conditions.

High frequency polling according to the present invention effectivelytransfers at least some of the power burden (and preferably as much ofthe power burden as possible under the circumstances) from the PIMD 802to the PPC 800 when effecting communications between the PIMD 802 andthe PPC 800. High frequency polling according to embodiments of thepresent invention exploits the uniqueness of the source of data (i.e.,the PIMD 802), PPC interaction with the PIMD 802, and APM serverinteraction with the PPC 800. The time and need for high frequencypolling is dependent on a number of factors, including the type of PIMD802 (e.g., anti-bradycardia device vs. CRT device), the type and volumeof data needed over a given time period, and the various needs forcommunicating with the PIMD 802, among others (e.g., when the PPC 802 issensing PIMD problems).

High frequency polling is particularly useful for reducing excessivepower consumption by the PIMD 802 associated with PIMD “wake up” andother status inquiry events. Implementations of the high frequencypolling according to the present invention exploit the PIMD's use oflower power when “listening” to an external device in comparison to thePIMD's need for higher power when “squawking” to an external device. Thestatus and/or wake-up strategy implemented by the PPC 800 and PIMD 802(or by the combination of the PPC 800, PIMD 802, and APM server 805)preferably moves the power burden from the PIMD 802 to the rechargeablePPC 800 as much as possible.

For example, a PIMD 802 may be operating at a low power level andawakened by the PPC 800 when needed. After the PIMD 802 is awakened,polling of PIMD data may be increased, resulting in a correspondingincrease in PIMD power consumption. According to one approach, atwo-mode wake-up strategy may be implemented based on a “status” modeand an “interrogation” mode. A status wake-up event preferably occursrelatively frequently, such as once per n hours, where n typicallyranges between 1 and 6 hours, for example. This status wake-up event ispreferably a low power event that involves transmission of a shortduration message from the PIMD 802 to the PPC 800 indicating that thePIMD 802 has nothing to report (which may also be reported to the APMserver 850). An interrogation wake-up event preferably occurs relativelyinfrequently, such as once per day, for example. This interrogationwake-up event is typically a higher power event that involves a PIMDinterrogation and transmission of interrogation data from the PIMD 802to the PPC 800 (and subsequently to the APM server 850).

A tiered PIMD polling methodology may be employed in accordance withembodiments of the present invention. According to some embodiments, atiered polling approach involves the PPC 800 (by itself or in responseto a command signal from the APM server 850) transmitting a ping to thePIMD 802. In response to the ping, the PIMD 802 transmit a signalindicating (1) that the PIMD 802 does not need to establish acommunications/interrogation link or require a status check, or (2) thePIMD 802 needs to be interrogated, in which case a communications linkis established between the PPC 800 and the PIMD 802, which requirespowering up of the PIMD's transceiver and other necessary components.

If the result of the ping indicates that the PIMD 802 cannot be locatedor the PPC 800 is out of range, then a message is preferably sent viacell or land phone, email, or otherwise to the patient that the PPC 800needs to be carried to establish required communication with the PIMD802. If the result of the ping indicates that all is nominal, and thatthis nominal status is confirmed n times over m hours (e.g., 10 timesover 10 hours), then it is assume that all is nominal. In this scenario,it is the PPC 800 that is predominately consuming power rather than thePIMD 802, which is preferred since the PPC's power source is typicallyrechargeable. If it is determined from historical data that the patientalmost always carries the PPC 800, such as by repeated successfulreceipt of a signal from the PIMD 802 in response to a ping, the pollingstrategy may be modified from a pinging strategy to some other lowerpower strategy, such as scheduled strategy via remote programming by theAPM server 850.

According to another approach, a hybrid ping methodology may beimplemented in which the PIMD 802 performs some level of pinging and thePPC polls on a regular basis. By way of example, the PIMD 802 may beprogrammed to transmit a ping signal on a regular basis (e.g., everyhour or few hours) in order to determine if the PPC 800 is in range. ThePPC 800 may be programmed to poll the PIMD 802 on a regular basis, asdiscussed previously. To combined approach of limited PIMD pinging andPPC polling provides for increased opportunity to determine PIMD statusand, if necessary, establish connectivity between the PIMD 802, PPC 800and/or the APM server 805.

A pinging methodology may also be used to assess the signal strength bythe PIMD 802 or the PPC 800. This assessment may be used by the PIMD 802and secondarily the PPC 800 to dynamically modify the device's networkinterface transmission power. For example, a ping transmitted by the PPC800 may be assessed by the PIMD 802 to determine the amount of powerneeded for the PIMD 802 to effect communications with the PPC 800 (ifneeded). The ping may be assessed by the PIMD 802, for example, todetermine the minimal amount of power needed for the PIMD 802 totransmit a signal responsive to the ping that will be received by thePPC 800. It will be appreciated with the PIMD 802 can dynamically assessits transceiver power needs based on each ping or other type ofsignaling generated by the PPC 800. In a similar manner, the PPC 800 canregulate its transceiver power as needed, although PIMD powerconservation preferably predominates over that of the PPC 800.

Other methods of implementing PIMD wake-up strategies are contemplated.For example, acoustic signals generated from a source outside thepatient's body may be detected by the PIMD 802 (e.g., via anaccelerometer or microphone). An acoustic signal have particularcharacteristics that are recognizable by the PIMD 802 may be generatedby the PPC 800. For example, the acoustic signal may be encoded with acommand signal and/or be of a particular frequency that would make thissignal relatively unique yet detectable by the PIMD 802. An ultrasonsicsignal or an inductive signal, for example, may be used for thispurpose. In one approach, the PPC 800 may be equipped with a sensor thatsenses a physiologic parameter of the patient when holding, or is inproximity with, the PPC 800. A heart rate sensor of the PPC 800, forexample, may detect an abnormal heart rate and, in response, the PPC 800may transmit a wake-up signal to the PIMD 802.

In another approach, the PPC 800 generates a signal that can be sensedby a lead/electrode arrangement of the PIMD 802. For example, a codedsignal transmitted by the PIMD 802 may be sensed by the PIMD 802 via thePIMD's lead/electrode arrangement, filtered, and detected by the PIMD802 as a wake-up signal. This approach has the advantage of notrequiring any additional sensing or power usage by the PIMD, sincesensing via its lead/electrode arrangement is a normal function.

A tiered wake-up/interrogation strategy may be implemented depending onneeds of the particular patient or present condition of the patient. Forexample, one approach involves the PIMD 802 waking up in response to afault condition or detection of a serious patient condition. Anotherapproach involves establishing a PIMD/PPC connection whenever possibleand terminating the connection after needed data is exchanged. A morepower consuming approach involves maintaining a continuous connectionbetween the PIMD 802 and PPC 800 whenever possible.

A wake-up or interrogation strategy may be implemented that involvesdetermining the current status of the patient and/or time of day priorto effecting PIMD wake-up. For example, the PIMD 802 may detect patientsinus tachycardia indicative of normal elevated heart rate, such as dueto exercise. An accelerometer of the PIMD 802 may detect patientactivity level and/or posture. These and other sensors may be used bythe PIMD 802 to determine whether effecting PIMD wake-up orinterrogation would be appropriate based on the sensed status of thepatient. This sensor information provides contextual information aboutthe patient's current status that may indicate that PIMDwake-up/interrogation is or is not desirable or useful. For example, itmay be necessary to obtain PIMD data each day when the patient is atrest. PIMD power may be conserved by the PIMD 802 first detecting whenthe patient is at rest prior to establishing a connection with the PPC800, even if prompted by the PPC 800 or by a pre-scheduled timer signal.

PPC with SIM Card

A SIM card used in a PPC of the present invention may be configured toenhance manipulation by the patient. Today's SIM cards used inconventional cell phones are typically difficult to grasp andmanipulate, particularly by older, impaired patients. A sleeve orcarrier that engages or encompasses the SIM card may be used make theSIM card easier to handle. In another configuration, the SIM card orcircuit may be permanently soldered to the PPC circuitry, thuspreventing removal and/or swapping of the SIM cards from theirdesignated PPCs. In one configuration, a silicon SIM card may be used,in which case stored SIM card data can be mapped to a SIM card ofanother PPC by the APM server.

Use of a SIM card in a PPC provides a convenient way for tracking PPCusage, allowing cellular network operators to bill for PPC usage basedon SIM card usage information. There are a number of ways in which a PPCthat incorporates a SIM card can be initiated into service. One approachinvolves forcing the SIM card into service on a specified date and time.Another approach involves activating SIM card usage the first time theSIM card detects a network connection. According to one automaticprovisioning approach, a number of pre-activation processes involvingthe SIM card may be enabled by the cellular network provider on ano-charge basis.

For example, installation and testing of a SIM card with a PPC duringmanufacturing or distribution is preferably enabled by the cellularnetwork provider without incurring charges. This allows the medicaldevice manufacturer increased flexibility during build, installation,testing, and distribution phases. Another approach involves granting a“free” number of minutes to accommodate the manufacturer's needs duringthese phases (e.g., 15-60 minutes). Accordingly, the PPC is ready forinstant activation, out-of-the-box, upon first transmission to thenetwork. Network charges only begin accruing after this initial PPCactivation event (or expiration of the predetermined “free” usageperiod). In one approach, the APM server may be configured by an ISP toallow the PPC to connect to the network.

A data block methodology may be used on a PPC's SIM card to provideenhanced security in cases of loss or theft of a patient's PPC. A uniquekey code, for example, may be stored on the PPC's SIM card for enhancingsecurity. This unique key code can incorporate coded information basedon a variety of data, including calibration parameters frommanufacturing, use parameters, a copy of medical or device data from thePIMD stored on a SIM data block, special phone numbers, special networkaddresses, etc. Enhanced security pairing may be implemented so adesignated SIM card is used only with a designated PPC.

Another approach may involve use of a bar code or other authorizationcode on the packaging of a new PPC, which can be input along with otherneeded information to authenticate and authorize use of the new PPC bythe APM server. A further approach may involve shipping a new PPC with adepleted battery, so that the new PPC cannot be inadvertently turned onand activated other than by the designated patient. It is noted thatinitializing a PPC for connection with the APM server may be performedusing a data channel of the cellular network rather than a voicechannel. In current cellular networks, the data channel typically hasbetter signal strength than the voice channel (i.e., 6 dB better signalstrength than the voice or audio channel).

According to various embodiments, a SIM card is used to storeinformation other than or in addition to data traditionally stored inSIM cards used in cellular phones. In this regard, such SIM or smartcards may be referred to more generically as identity cards or identitymodules that are configured to store data for a variety or purposes inaddition to providing for subscriber identification. For example, anumber of configuration parameters may be stored on a SIM card thatdescribes the various functions that can be performed by a particularPPC. The configuration parameters may define options and functions thatmay be selectively enabled and disabled. These configuration parameters,options, and/or functions may be embodied in a list of attribute/valuepairs, or in an XML-based configuration file, for example.

Various software codes may be stored in the SIM card and executed atpredetermined times or under predetermined conditions. For example,software code stored on the SIM card can be executed during PPCinitialization and reset processes. These processes may be related toPPC configuration or tailoring the PPC for specific tasks that aphysician/clinic prescribes for that specific patient, such as byenabling/activating prescribed functionality and/or features. Softwarecode may be stored on the SIM card for initiating and performing PPCservice diagnostics. The SIM card provides a flexible facility to haverelatively short scripts delivered to the PPC. These scripts may beconfigured to drive diagnostic code execution via an interpreterresident in the PPC firmware, for example, among other processes.

With reference to FIG. 13, for example, there is shown a PPC 800configured to provide enhanced functionality. The PPC 800 shown in FIG.13 preferably incorporates features in addition to those provided in areduced feature set PPC. According to various embodiments, the PPC 800may include a number of components and/or sensors, several non-limitingexamples of which are shown in FIG. 13. The PPC 800 may, for example,incorporate a SIM card 810, which may store data unique to the PIMD 802and/or the PPC 800 that is paired with the PIMD 802. Data stored in theSIM card 810 or other type of detachable smart card may store varioustypes of data regarding the PIMD 802, PPC 800, and other patient-relateddata. Incorporation of a SIM card 810 in a PPC 800 of the presentinvention advantageously facilitates easy transferring of data stored inthe SIM card 810 to another PPC 800, such as when upgrading to adifferent PPC 800 or when replacing a defective PPC 800. Use of a SIMcard 810 may significantly reduce the amount of information needed torealize full operation of a newly paired PIMD 802 and PPC 800. It isnoted that SIM card 810 may be configured to incorporate core cellulartechnology into the card itself (e.g., W-SIM), which may simplify thedesign of the PPC (and reduce cost of a PPC having a reduced featureset).

PPC with Physiologic Sensors

As is further shown in FIG. 13, the PPC 800 may also incorporate amodule port 816 configured to receive a memory or processor module thatallows for enhanced operation of the PPC 800. For example, the moduleport 816 may be configured to receive a memory module that providesincreased storage for PIMD data, such as cardiac event data, EGM or ECGwaveforms, cardiac signal templates, diagnostic data, and the like. Forexample, attachment of a memory module to the module port 816 allows agreater volume of PIMD data to be buffered by the PPC 800 duringextended periods of non-communication between the PPC 800 and an APMserver (e.g., due to weak or inadequate cellular connections, no-servicelocations, periods of high network traffic, etc.).

The PPC 800 shown in FIG. 13 includes one or more physiologic sensorsconfigured to sense one or more physiologic parameters of the patient.For example, the sensors 805 may include metallic sensors for contactingwith the patient's skin through which the patient's heartbeat isacquired. The sensors 805 are coupled to electronics (e.g., amplifies,filters, signal processors, and/or other circuitry) that provide aheartbeat signal detector within the PPC 800. The PPC 800 may beequipped with other sensors for sensing any type of physiological data,including an accelerometer, microphone (e.g., heart sounds and/or lungsounds monitor when the PPC 800 is held near the heart), a posturesensor, motion sensor, pulse oximeter, photoplethysmography sensor, abody weight, fat or fluid change sensing arrangement, optical orphotonic blood chemistry sensors, blood pressure sensors, and bodytemperature sensors, among others. As was discussed previously, one ormore of these sensors may be used during a pairing operation. Ambientcondition sensors may also be incorporated in the PPC 800, such as anambient temperature, pressure, and/or hygrometer sensor.

Time stamp data may be appended to sensor data and/or an event markermay be appended to sensor data that results from patient actuation of aPPC button when an event is felt by the patient. This aids in timecorrelating sensor data to other physiologic data and contextual events.Timing (e.g., clock time) used by the PIMD 802 and PPC 800 may becoordinated or synchronized using various time/clock standards, such asAPM server time, PIMD clock time, programmer clock time, time zone timebased on geographical location of the PPC 800, time indicated bycellular infrastructure, or other standard.

As is shown in FIG. 13, weight, fat or fluid monitoring circuitry withinthe PPC 800 may be coupled to a number of metallic skin contacts orelectrodes 805 that provide for physical and electrical coupling betweenportions of the user's anatomy and the monitoring circuitry of the PPC800. According to one arrangement, two electrodes 805 serve as sourceelectrodes and two electrodes 805 serve as detection electrodes. Ingeneral terms, changes in body weight, fat or fluid may be determined bymeasuring changes in the resistance of the body to an injectedmonitoring signal using a four point probe technique. The monitoringcircuitry includes a monitoring signal generator, which is typically acurrent or voltage source that provides a constant current or voltagemonitoring signal. The monitor signal generator is coupled to the twosource electrodes 805. The monitoring circuitry further includes avoltage detector which is coupled between the two detection electrodes805. The voltage detector typically receives an input reference signalfrom the monitoring signal generator. The monitoring signal generatorpreferably generates an AC drive current signal. The drive currentsignal can be a sinusoidal signal or a square wave.

A monitoring signal generated by the monitoring signal generator isinjected into the user's body via the source electrodes 805. A currentfield is produced between the source electrodes 805 in response topropagation of the monitoring signal into the user's body tissue. Thedetection electrodes 805 are situated such that the current field isdetectable. A sense voltage is developed between the detectionelectrodes 805 and measured by the voltage detector. An impedance,Z_(bio), may be derived using the sense voltage and source currentamperage. The derived impedance value is reflective of a biologicalresistance and reactance (i.e., bioimpedance, Z_(bio)) measurablebetween the detection electrodes 805 in response to the monitoringsignals injected into biological tissue by the source electrodes 204.Changes in sense voltage or bioimpedance may be correlated to changes inbody weight, fat or fluid, which may be particularly useful whenmonitoring patient heart failure status, for example.

The PPC 800 shown in FIG. 13 may include one or more accelerationsensors 803 coupled to a microcontroller or processor of the PPC 800. Anacceleration sensor 803 may be used for a variety of purposes, includingposture sensing, activity sensing, heart rate sensing, heart soundsensing, and as a step counter of a pedometer for counting steps takenby a user during walking or running. Inclusion of one or moreacceleration sensors 803 provides a number of pedometer functions,including step counting, distance computations, and caloric consumptioncalculations. By entering the user's stride length and weight intomemory of the PPC 800, for example, the processor of the PPC 800 cancalculate various statistics of interest, including total distancetraveled, total calories burned, speed, elapsed time, and steps perminute. As discussed previously, inclusion of pedometer functionalityinto the PPC 800 may provide an incentive for the patient tocontinuously carry (or remember to carry) the PPC 800.

PPC with Rechargeable Hub

FIG. 14 shows a base station or hub 1000 that is configured tophysically and electrically receive the PPC 800. The hub 1000 includes apower cord and connector for connecting with a standard wall socket(e.g., 110-120V, 60 Hz household power source). The hub 1000 mayalternatively or additionally include power circuitry appropriate for a220V/50 Hz power source or other power source, as is widely used inEurope. The power supply circuitry of the hub 1000 may be configured toautomatically sense the voltage of the power source and automaticallyswitch appropriate circuitry to safely couple to the power source, whichis particularly useful when traveling between the United States andEurope, for example.

The hub 1000 may also include a telephone, modem, or networkcommunications interface 1012 that allows for connection to atraditional land line (e.g., POTS or cable) communication link. The hub1000 may incorporate or be connectable to a Wi-Fi node/wireless accesspoint for communicating with a household Wi-Fi system. The hub 1000 mayalso include an antenna arrangement that can be used to increase theantenna range for the PIMD, such as for PIMD interrogation. The antennaarrangement of the hub 1000 may also be configured to host Bluetooth orother communication paths between the hub 1000 and one or more externalsensors and/or between the PIMD and one or more external sensors. Thehub 1000 preferably includes the same radios as are included in the PPC800.

The hub 1000 is shown to include a display 1002. The display may beconfigured to display text and graphics (e.g., LCD or OLED), such asdata and waveforms received from the PPC 800. The hub 1000 may includeone or more status indicators 1004 and one or more user interfacebuttons or controls 1006. The hub 100 may also include or couple to oneor more physiologic sensors that can acquire physiologic signals fromthe patient. Such sensors include a blood pressure cuff arrangement,weight scale, pulse oximetry sensor, thermometer, and heart ratemonitor, among others. Data acquired by such sensors may be stored bythe hub 1000 and/or transferred to an APM server. The hub 1000 mayinclude an array of Bluetooth transceivers and/or transceiver connectors(built-in and/or external) to allow for an expanded number of sensors tocommunicate with the hub 1000. Time stamp data may be appended to thesensor and PPC data, which preferably includes unique ID data (e.g., SIMcard ID, PIMD ID), and may also include ID of the hub 1000 and/or PPC800 or a combination of these ID data.

A connector 1013 of the hub 1000 is configured to receive acorresponding connector 813 of the PPC 800. Mating engagement of the twoconnectors 813, 1013 establishes data connectivity and, preferably,power connectivity between the hub 1000 and the PPC 800. The twoconnectors 813, 1013 may be USB connectors. For example, power isdelivered to the PPC 800 when the connector 813 of PPC 800 is mated tothe connector 1013 of the hub 1000, thereby recharging the rechargeablebattery of the PPC 800 (e.g., lithium ion, lithium polymer, or nickelmetal hydride battery). Mating engagement of the two connectors 813,1013 facilitates transfer to data and power between the PPC 800 and thehub 1000. The hub 1000 may be programmed to initiate charge/dischargecycling of the PPC 800 to promote extended PPC battery life.

PIMD data acquired by the PPC 800 during ambulatory use by the patientmay be transferred to a memory 1010 of the hub 1000. This data may betransferred to an APM server via the communications interface 1012. Itis understood that a local wireless communication link may also beestablished between the PPC 800 and hub 1000 using components andprotocols discussed previously, in which case a simple power connectorbetween the PPC 800 and hub 1000 may be used to recharge the battery ofPPC 800. It is further understood that the PPC 800 may be capable ofproviding full functionality while seated in the hub 1000.Alternatively, selected functionality may be enabled or disabled whenthe PPC 800 is seated in the hub 1000.

The PPC 800 shown in FIG. 14 includes various features that may beconsidered optional. The PPC 800 is shown to include an opticalemitter/detector 811 that may be used to facilitate pulse oximetry orphotoplethysmography sensing. For example, the patient may simply placea finger or thumb over the optical emitter/detector 811 and push button801 to initiate an optical sensing procedure. The circular sensors 807and 809 may represent other types of sensors that may incorporated inthe PPC 800, such as those previously described. For example, the uppertwo sensors 807 and lower two sensor 809 may represent metal contactsensors that may replace or compliment the sensors 805 disposed on thesides of the PPC 800. The PPC 800 may provide wireless or wiredconnectivity with other patient sensors, such as a Holter monitor orother physiologic sensor separate from the PPC 800. The PPC 800 mayitself define a Holter monitor, with sensors being connected to the PPC800 at an appropriate wired or wireless interface.

The PPC 800 shown in FIG. 14 includes a simple display 806, whichincludes a battery indicator 819, a signal strength indicator 817, and apush button 801. The PPC 800 may also include an alert module 823 thatgenerates an alert signal in response to a condition requiring immediateattention. The alert module 823 may be coupled to a visual, audible orvibratory component of the PPC 800. The alert module 823 may also beconfigured to transmit a message to the patient's cell phone, pager, thehub 1000, or the APM server 850 in response to an alert condition. PPC800 includes a memory 825, which may be configured to store variousfirmware, software, and data, including software that facilitatespairing of a PIMD 802 with a PPC 800.

The hub 1000 may incorporate a number of features that can enhancemanagement of PIMD and PPC power resources. For example, the PIMD 802may monitor its battery capacity relative to a threshold. When thebattery capacity falls below this threshold, as detected by the PIMD802, PPC 800 or hub 1000, the hub 1000 or the PPC 800 automaticallyinitiates a call or dispatches a message via any available mechanism tothe APM server 850 alerting the server that the PIMD battery is nearingdepletion. The PPC 800 or hub 1000 may also make an automatic call tothe patient's cell phone, home phone, or advocate's phone, such as aphysician's office phone. The threshold is preferably established toallow enough time for the call or message to be dispatched and respondedto by the APM service, which includes time for the patient to travel toa hospital or care facility.

The hub 1000 or PPC 800 may be programmed to trend the charge history ofthe PPC 800 and evaluate the health of the PPC's battery. If thecharging trend indicates the PPC's battery is failing, a call or messagemay be communicated by the PPC 800 or hub 1000 to the APM server 850that the PPC's battery requires replacement or evaluation. The PPCbattery may be replaced the next time the patient visits his or herphysician, for example. A call may be placed by the PPC 800 or hub 1000ahead of the patient's office visit to indicate that PPC batteryreplacement is needed, allowing the office to obtain the necessarybattery in time for the patient's visit. A signal or light on the hub1000 and/or PPC 800 may be illuminated to indicate that a new battery isneeded based on the history/trend data. The hub 1000 preferably tracksthe battery charge status of PPC 800 and knows how much PPC usage timeis left (e.g., x=13 hours). The hub 1000 may be programmed to initiate acall to the patient's home or cell phone to indicate that the PPC'sbattery needs to be charged.

The hub 1000 may include an indicator that beeps or flashes to indicateto the patient that the PPC 800 has not been cradled on the hub 1000 forx days or hours. This indicator prompts the patient to connect the PPC800 to the hub 1000 for recharging and any needed or desirable dataexchange between the PPC 800/hub 1000/APM server 850. The hub 1000 mayuse a USB connector, for example, that connects with and provides powerto the PPC 800 when cradled on the hub 1000.

Multiple hubs 1000 may be used in the same home or facility. Multiplehubs 1000 provides the opportunity to perform enhance functions, such asperforming SIM to SIM transfers for replacing PPCs 800 having poorperformance. Multiple PPC slots may be provided in a single hub 1000,allowing a single hub 1000 to provide hub functionality (e.g., landlinelink to the APM server 850) for multiple PPCs 800.

As was discussed previously, the hub 1000 can communicate with the APMserver 850 to acquire updates for the PPC 800 before the patient returnshome, so that the update is immediately available when the PPC 800 iscradled on the hub 1000. A touch screen 1002 of the hub 1000 may, forexample, be provided to facilitate patient interaction with the hub1000, such as to verify updates from the APM server 850 to the PPC 800.The APM server 850 may provide alerts to the hub 1000 that are to bedownloaded to the PIMD 802 via the PPC 800/hub 1000. In one approach,programming changes to the PIMD 802 may only be instigated when the PPC800 is set in the cradle of the hub 1000. The hub 1000 may be locked inor out when the PPC 800 is seated (e.g., during remote programming). Anindicator of an addition or change to PIMD alerts or software may becommunicated to the patient via the hub 1000, and patient authorizationor consent to make the programming change may be given by patientactuation of an approval or PIMD update button.

The hub 1000 may be implemented to provide additional features. Forexample, the hub 1000 may be used by the patient's caregiver tocommunicate with the APM system 850 and/or PPC 800 via the hub's userinterface devices. The hub 1000 may include a backup power supply thatprovides power to the PPC 800 and hub 1000 if local line power isinterrupted or lost. The backup power supply may be sufficiently largeto provide recharging for the PPC's battery. The hub 1000 may have abackup memory that stores the latest firmware, setting, andconfiguration data (e.g., redundant configuration data/firmware) for thePPC 800 and/or PIMD 802, which can be accessed as part of a quickrecovery mechanism. The hub 1000 may include a “locate PPC feature” thatincludes a button that, when actuated, transmits a “find signal” to thePPC to assist the patient/caregiver in locating the PPC.

The hub 1000 may incorporate voice synthesizer circuitry or voice fileplayback circuitry to convert voice/audio files to human speech. Audiomessaging may be uni-directional or bi-directional as between the hub1000 and the APM server 850. For example, messages transferred from aphysician, clinician, or technician (e.g., employee of the APM service)via the APM system 850 to the hub 1000 may be played back in humanspeech form by audio circuitry/components of the hub 1000. Audio filesmay be transferred in WAV or MP3 format, for example. The hub 1000 mayallow the patient or caregiver to record messages and transmit thesemessages to a recipient via the APM server 850. A “live” audio sessionbetween the patient/caregiver and the physician, clinician, ortechnician may be implemented using a landline connection, wirelessconnection, or voice-over-Internet connection established using the hub1000.

Software Architecture

FIGS. 15-17 provide an overview of software architecture for a PPC inaccordance with embodiments of the invention. In general, the PPC isresponsible for interrogating status and data from the PIMD (e.g.,implantable pulse generator or PG) and relaying the information to theAPM server. The PIMD interrogation is preferably initiated on a regularbasis according to a predetermined schedule, at the request of theclinician via the APM server, or at the request of a patient via abutton on the PPC. The PPC must also periodically contact the APM serverto get any updates to the schedule, configuration, software, orcommunicator status. Server-initiated connections are desirable for thePPC, which can be implemented using a server-push paradigm, rather thana PPC-pull paradigm.

FIG. 15 is a high level software architectural overview that shows therelationships between various tasks and the events and information thatflow between these tasks. FIG. 15 shows the main PPC software tasksincluding the main tasks of monitoring the interrogation schedule 1104,performing PIMD (e.g., PG) communications 1106, performing servercommunications 1108, and interacting with the user interface 1102. It isunderstood that the term “task” used in the context of the PPC softwarearchitecture does not necessarily imply a task in the sense of aseparate thread of execution within the system. It is used here as ageneric term for the partitioning of the functional duties of thesoftware. The timing granularity and responsiveness of all operations atthis architectural level are preferably on the order of hundreds ofmilliseconds.

The main task 1104 involves monitoring the PPC schedule for scheduledPIMD interrogations or APM server communications. Another main task 1104is monitoring the PPC user interface for patient-initiatedinterrogations. The main task 1104 is responsible for initiating andmonitoring PIMD interrogations, initiating and monitoring APM servercommunications, and accepting APM server communication requests. Thetiming granularity and responsiveness of all main task operations arepreferably on the order of 100 ms. Persistence requirements include PPCschedule and software version information.

Responsibilities of PIMD (e.g., PG) communications task 1106 includeinitiating a PIMD communication session via RF telemetry, interrogatingstatus and data from the PIMD, streaming real-time data from the PIMD,including EGM and marker data, and terminating the PIMD communicationsession. Concerning timing requirements according to variousimplementations, the physical layer protocol may require the ability toservice a symbol every 39 μs. The physical layer protocol may requirethe ability to process a frame and be ready for the next frame withinabout 50 μs of processing time (i.e., the link turnaround time).Persistence requirements, according to various embodiments, may includePIMD session credentials, such as model number, serial number, wakeupaccess code, permanent HMAC key, and PIMD center frequency. Persistencerequirements may also include PIMD payload results, which may be on theorder of 100 to 300 KB each, up to three payloads.

In accordance with some embodiments, the PIMD communications task 1106of the PPC may be implemented using a serial peripheral interface bus(SPI), a microprocessor with wireless functionality, such as WirelessMicroprocessor Model No. WMP100 manufactured by Wavecom S.A. ofIssy-les-Moulineaux Cedex, France, and a radio transceiver chip, such asModel No. CC1110 available from ChipCon or Texas Instruments. Anexternal interrupt is provided into the WMP100, and one general purposeInput/Output (GPIO) line out of the WMP100 is provided to communicatewith the CC1110 transceiver chip. The WMP100 is preferably the SPImaster. The CC1110 raises an interrupt into the WMP100 when it has datato send. The WMP100 drives the GPIO line to control the operating stateof the CC1110.

The layering of the functional blocks within the PIMD communicationsprotocol stack is depicted in FIG. 16. FIG. 16 shows how thefunctionality is mapped onto the processor 1201 and communicationscircuitry 1121 of the PPC in the “two-chip” embodiment shown in FIG. 16.It is noted that the timing requirements become tighter as one movesdown the protocol stack. The elements 1201, 1221, 1223 (Intel 8051processor), 1225 (ChipCon RF transceiver), and 1232 shown in dashedlines in FIG. 16 indicate hardware components. The solid boxes of theprocessor 1201 and those in the communications circuitry 1221 indicateindividual software modules within the PIMD communications softwarecomponent.

Responsibilities of the server communications task 1108 includeestablishing or accepting an SSL connection to/from the APM server,accepting configuration, schedule, software version, and other data fromthe APM server, and uploading PIMD interrogation data to the APM server.Other server communications task responsibilities include supportingreal-time data streaming to the APM server or other destinationapplication, and terminating the APM server connection. Concerningtiming requirements, all interactions are preferably be on the order of100 ms, as previously discussed. Persistence requirements include APMserver contact information (URL, username, password), APM servercredentials (authentication certificates), and PPC credentials(authentication certificates), among others.

According to some embodiments, the user interface of the PPC is ofminimal complexity, and may include one or two buttons, a few LED's,possibly a very simple display, and possibly a buzzer. Responsibilitiesof the user interface task 1102 include indicating interrogation status,signal strength, and data upload status, providing device alertindications, and facilitate patient-initiated interrogation.

FIG. 17 shows server communications in functional block diagram form inaccordance with embodiments of the invention. In accordance with variousembodiments, particularly those that incorporate a wirelessmicroprocessor such as the Wavecom WMP 100, desirable or useful devicedriver and support features may include the following software supportand hardware peripherals, as is shown in FIG. 17. Software supportfeatures according to some embodiments may include XMLparsing/generation; digital signature verification/generation (RSASHA-1); HTTP 1.1; SSL 3.0; TCP/IP; PPP (TCP over point to pointprotocol); a GSM link; and flash storage access for persistent statedata. Hardware peripherals and features according to some embodimentsmay include: user interface—buttons, LEDs, SPI—one master, batterycharging/management, USB device or host/on-the-go interface, serialinterface to POTS/cell modem, Ethernet interface (optionally), very lowinterrupt latency, and a timer granularity that provides frequentupdating, such as every 20 ms.

Various modifications and additions can be made to the preferredembodiments discussed hereinabove without departing from the scope ofthe present invention. Accordingly, the scope of the present inventionshould not be limited by the particular embodiments described above, butshould be defined only by the claims set forth below and equivalentsthereof.

What is claimed is:
 1. A patient communicator for communicating with apatient implantable medical device (PIMD) and facilitatingcommunications with a remote server via a wireless network, the patientcommunicator comprising: a housing configured for portability by anambulatory patient; an identity module disposed in the housing andconfigured to store subscriber identification data; a processor disposedin the housing and coupled to the identity module, wherein the processoris configured to prevent data exchange with the PIMD unless the identitymodule is authorized for use; memory disposed in the housing and coupledto the processor, wherein the memory comprises wireless radio firmwareand medical firmware, wherein the medical firmware is executable by theprocessor to facilitate communication with the PIMD, a first radiodisposed in the housing and configured to effect communications with thePIMD in accordance with execution of the medical firmware by theprocessor; a second radio disposed in the housing and configured toeffect communications via a channel of the wireless network with aremote server in accordance with execution of the wireless radiofirmware by the processor; and the processor configured to use at leastthe subscriber identification data to facilitate authentication by theremote server and facilitate authentication of the remote server.
 2. Thecommunicator of claim 1, wherein the identity module is removablydisposed in the housing.
 3. The communicator of claim 1, wherein theprocessor is configured to pair with the PIMD using the identity module.4. The communicator of claim 1, wherein the subscriber identificationdata uniquely identifies the patient, and the subscriber identificationdata comprises physiologic data obtained from the patient.
 5. Thecommunicator of claim 4, wherein the physiologic data is obtained fromthe patient during an initial pairing of the patient communicator andthe PIMD.
 6. The communicator of claim 1, wherein the subscriberidentification data comprises PIMD programmer data.
 7. The communicatorof claim 1, wherein the subscriber identification data stored in theidentity module comprises decoder logic for facilitating communicationwith the PIMD.
 8. The communicator of claim 1, wherein configurationdata is stored in the identity module, the configuration data comprisingconfiguration parameters that are selectably enabled by the processor toenable selected functions.
 9. The communicator of claim 1, the identitymodule further comprising software code executable by the processor forinitialization and reset processes.
 10. The communicator of claim 3,wherein the processor uses the subscriber identification data tofacilitate data exchange only with the PIMD to which the identity moduleis paired.
 11. A patient communicator for communicating with a patientimplantable medical device (PIMD) and facilitating communications with aremote server via a wireless network, the patient communicatorcomprising: a housing configured for portability by an ambulatorypatient; an identity module detachably disposed in the housing andconfigured to store at least identity data that uniquely identifies thepatient communicator as being associated with the patient, wherein theidentity data comprises physiologic data obtained from the patient; aprocessor coupled to the identity module, wherein the processor isconfigured to pair with the PIMD using the identity module and allowdata exchange with the PIMD if the identity module is authorized foruse; memory disposed in the housing, wherein the memory compriseswireless radio firmware executable by the processor and medical firmwareexecutable by the processor, a first radio disposed in the housing andconfigured to effect communications with the PIMD in accordance withexecution of the medical firmware by the processor; a second radiodisposed in the housing and configured to effect communications with aremote server via a wireless network in accordance with execution of thewireless radio firmware by the processor; and the processor configuredto use at least the identity data stored in the identity module andexecute program instructions for (a) facilitating authentication by theremote server prior to permitting access to the remote server and (b)facilitating authentication of the remote server prior to permittingaccess by the remote server.
 12. The communicator of claim 11, whereinthe identity data stored in the identity module comprises anauthentication key configured for authentication by the processor. 13.The communicator of claim 11, wherein the physiologic data is obtainedfrom the patient after pairing with the PIMD.
 14. The communicator ofclaim 11, wherein the processor is configured to transmit at least someof the identity data and PIMD data to the remote server, wherein the atleast some of the identity data is configured to update patient data onthe remote server.
 15. The communicator of claim 11, the identity modulefurther comprising a carrier feature to facilitate grasping by thepatient.
 16. The communicator of claim 11, wherein the identity moduleis embodied in a semiconductor chip.
 17. The communicator of claim 11,wherein the identity data is mappable to a second identity module of asecond patient communicator by the remote server.
 18. The communicatorof claim 11, wherein activation of wireless network services foreffecting patient communicator communications is based on detection of awireless network connection by the processor using the identity data.19. A method for effecting communications between a patient communicatorand a patient implantable medical device (PIMD) and for facilitatingcommunications between the patient communicator and a remote server viaa wireless network, the method comprising: identifying a paired PIMD bya processor using physiologic data obtained from the patient, whereinthe physiologic data is stored in an identity module of the patientcommunicator; preventing data exchange between a patient communicatorand the PIMD unless the identity module of the patient communicator isdesignated for use only with the patient communicator; effectingcommunications between the PIMD and a first radio of the patientcommunicator in accordance with execution of the medical firmware by theprocessor; effecting communications between a second radio of thepatient communicator and a remote server via a wireless network inaccordance with execution of the wireless radio firmware by theprocessor; providing identity data stored in the identity module to theremote server for authentication by the remote server prior to accessingthe remote server; authenticating the remote server using the identitydata stored in the identity module prior to permitting access by theremote server; and exchanging at least PIMD data between the patientcommunicator and the remote server in response to successfulauthentication.
 20. The method of claim 19, comprising exchanging atleast the PIMD data between the patient communicator and the remoteserver via a channel of the wireless network other than a voice channel.